Closed Bug 968334 (CVE-2015-2707) Opened 10 years ago Closed 8 years ago

Unsafe Imap/Pop url protocol handling could lead to RCE

Categories

(MailNews Core :: Security, defect)

Product:
MailNews Core
Component:
Security
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(firefox38 fixed, firefox38.0.5 fixed, firefox39 fixed, thunderbird38+ fixed, thunderbird39 fixed, thunderbird40 fixed, thunderbird_esr31+ affected)

Status:
RESOLVED FIXED
Milestone:
Thunderbird 40.0
Tracking Flags:
Tracking Status
firefox38 --- fixed
firefox38.0.5 --- fixed
firefox39 --- fixed
thunderbird38 + fixed
thunderbird39 --- fixed
thunderbird40 --- fixed
thunderbird_esr31 + affected

People

(Reporter: l.pontorieri, Assigned: neil)

References

Details

(Keywords: sec-high, Whiteboard: [reporter-external][adv-main38-])

Attachments

(6 files, 2 obsolete files)

Most critical scenario reproduced on linux
5.04 MB, video/ogg
Details
Potential approach
1.75 KB, patch
smaug
: review-
Details | Diff | Splinter Review
Updated for review comments and bitrot
6.39 KB, patch
smaug
: review+
Sylvestre
: approval-mozilla-beta-
Details | Diff | Splinter Review
Updated comm-central part of patch
1.00 KB, patch
standard8
: review+
standard8
: feedback+
rkent
: approval-comm-beta+
Details | Diff | Splinter Review
Branch-safe version of attachment 8574381
8.65 KB, patch
smaug
: review+
Sylvestre
: approval-mozilla-release+
Details | Diff | Splinter Review
Branch version of attachment 8586460
1.27 KB, patch
rkent
: review+
rkent
: approval-comm-aurora+
rkent
: approval-comm-beta+
Details | Diff | Splinter Review 
User Agent: Mozilla/5.0 (X11; Ubuntu; Linux i686; rv:24.0) Gecko/20100101 Firefox/24.0 (Beta/Release)
Build ID: 20130911160237

Steps to reproduce:

Mozilla Thunderbird handles imap procol unsafely. 
An attacker can force victim's client to do imap requests on his mail server.
It's possible to take advantage of this condition to force a target to download any kind of file on its computer spoofing its mime type and in the worst scenario to be directly opened/executed without user interaction.

An attacker can force an user to do an IMAP request sending a malicious HTML mail.
For example we could force him to FETCH his first email and to display it in iframe sending him:

<html>
<iframe src="imap://[email]@[ImapServer]:[Port]/fetch%3EUID%3E/INBOX%3E1"></iframe>
</html>

Username and ImapServer Port are not mandatory, we could simply send an html like this to obtain the same result: 

<html>
<iframe src="imap:///fetch%3EUID%3E/INBOX%3E1"></iframe>
</html>

The most interesting scenario is that we can force the victim to download a malicious attached file *without interacting*.
 
*Furthermore if the user has selected in the past which program to use to open those files, this will make him execute the program as soon as he opens the mail.*

<html>
<iframe src="imap:///fetch%3EUID%3E/INBOX%3E[EMAIL_ID]?part=[Part]&filename=[Arbitrary Filename]&type=[Arbitrary Mime Type]
</html>

If the user has not selected any program in the past, a download prompt will appear, asking to save or open the file.
In this case it could be useful to set up filename and type fields in the forced imap request.
Filename doesn't stand for the actual filename of the attached file, but an arbitrary string we can set. This is useful to bypass every SMPTD filters (like Googlemail; it forbids to send files with extensions like "exe").
Even more useful is "type". It stands for file mime type, it can be used to force to load the file with a program despite its extension.

By the way we need to set [EMAIL_ID] correctly without knowing it. 

From RFC 3501:

           Also note that a UID range of 559:* always includes the
           UID of the last message in the mailbox, even if 559 is
           higher than any assigned UID value.  This is because the
           contents of a range are independent of the order of the
           range endpoints.  Thus, any UID range with * as one of
           the endpoints indicates at least one message (the
           message with the highest numbered UID), unless the
           mailbox is empty.

So we can set email id as [Extremely large Number]:* to reach last email (our mail) attachment.
Another approach would be to "bruteforce" with a large number of iframes our email. 


This issue also affects POP3. 
In that scenario, because of the fact POP3 saves mail on the local disk, we have to bruteforce/guess maildir, or to try to create a "fake temporary file".
For example, on linux, Thunderbird creates tmp files when an attachment is opened: it's possible to send two different emails, the first one with the "email file" (with another safe ext) and the second one with attack code like

<html>
<iframe     src="mailbox:///tmp/faketmpfile.pdf?part=1.2&filename=[FILENAME]&type=[Type]">
</iframe>
</html>



Actual results:

It's possible to take advantage of Thunderbird Imap/Pop urls to force a victim to do actions without interacting (victim just opens the mail).


Expected results:

It's not possibile to force an execution/download or imap requests without user authorization.
Flags: sec-bounty?
Whiteboard: [reporter-external]

    
    

    
  
Why is Linux not treating shell scripts as "executable" files that can't be opened by default? That aside, though, a more likely attack scenario would be mail with MS office formats or PDF attachments using well known exploits and figuring lots of users haven't upgraded. Those are also formats most users probably check the "do this every time" box on.
Keywords: sec-high, 
          
            sec-vector
Product: Thunderbird → MailNews Core

    
    

    
  
(In reply to Daniel Veditz [:dveditz] from comment #2)
> Why is Linux not treating shell scripts as "executable" files that can't be
> opened by default? 

I'm investigating this, I understand this is an unexpected behaviour.
I just opened an .sh file and checked the box to open that file-type automatically.

> That aside, though, a more likely attack scenario would
> be mail with MS office formats or PDF attachments using well known exploits
> and figuring lots of users haven't upgraded. Those are also formats most
> users probably check the "do this every time" box on.

Yes, probably this is the most common attack scenario without user interaction. 

Obviously an attacker could use social engineering to trick the user to open a fake "Thunderbird update". Average user probably would open something TB shows "by itself".

Another idea is to trigger firefox/other browser to open a file and execute javascript on file:// protocol (I think this leads to local file disclosure, but I didn't test this).

    
    

    
  
On trunk we might be able to leverage bug 906276 to disable all undisplayable content. Unfortunately saving attachments currently relies on content retargeting, so some tweaking might be required.
Blocks: 968342
Group: mail-core-security

    
    

    
  
Hi Mark,

any idea what the issue is here?
Assignee: nobody → standard8
Flags: needinfo?(standard8)

    
    

    
  
The "issue" here is that Thunderbird uses the imap/pop uris to access attachments. If you outright block those, then things like displaying attached images/downloading attachments will just stop working.

The solution that Neil comments on in comment 4 is potentially possible, but I don't think I'm the right person to do that.

Neil would you be able to look at this?
Assignee: standard8 → nobody
Flags: needinfo?(standard8)
Keywords: sec-vector

    
    

    
  
@neil is this something you could help with?
Flags: needinfo?(neil)

    
    

    
  
neil?

    
    

    
  
Sorry I haven't had time to look at this, but I should have more time next month.
Group: mail-core-security

    
    

    
  
There was a websec issue with attackers using the view-source URL scheme in object tags (bug 973837) and iframes (bug 624883) to harm users. Could we leverage these pieces of code to fix this bug, or do we need iframe/objects pointing to imap and mailbox URL schemes for HTML emails?
Flags: needinfo?(standard8)

    
    

    
  
(In reply to Frederik Braun [:freddyb] from comment #10)
> There was a websec issue with attackers using the view-source URL scheme in
> object tags (bug 973837) and iframes (bug 624883) to harm users. Could we
> leverage these pieces of code to fix this bug, or do we need iframe/objects
> pointing to imap and mailbox URL schemes for HTML emails?

We need them pointing to imap and mailbox schemes so that we can e.g. display in-line attachments like pictures etc.

It might be conceivable just to block for iframes, not sure if this would cause issues with existing email use cases already out there (Joshua might know), or if that alone would be enough to fix this bug.
Flags: needinfo?(standard8) → needinfo?(Pidgeot18)

    
    

    
  
The main use of cid URLs is for <img src="cid:"> stuff. Conceivably you could also add in <audio> or <video> but I'm not sure how many email clients support those tags. Use of cid: in <link href=""> and in CSS url(cid:) values is also conceivable, but those are likely to be less well supported anyways.

I can't think of any usecase for an <iframe src="">. I am offhand worried, though, that the issue of the message rewriting URLs is larger than just iframes and equally applicable to <img src="">.
Flags: needinfo?(Pidgeot18)

    
    

    
  
Shouldn't our checkMayLoad checks prevent load of any imap:, pop3: schemes?  Isn't there any protocol flag to set/drop to achieve that?

    
    

    
  
(In reply to Honza Bambas (:mayhemer) from comment #13)
> Shouldn't our checkMayLoad checks prevent load of any imap:, pop3: schemes? 
> Isn't there any protocol flag to set/drop to achieve that?

It's a somewhat complicated situation. When we get a mime message that says <img src="cid:foobar">, we rewrite that in the MIME backend to say <img src="message URL?part=1.2.1&type=image/png"> so we can load the cid: reference properly. The message URLs that we use for IMAP messages are imap://imap.google.com:993/fetch%3EUID%3E/INBOX%3E224350.

    
    

    
  


  
Thank you for your patience. I have investigated my potential solution that I referred to in comment #4. The attached patch prevents attachments from opening automatically but still allows them to be opened manually. Possible issues:
* nsDocShell.cpp part of patch may not be acceptable
* Potential side-effects on RSS pages (this could perhaps be mitigated by toggling the retargeting in the content policy instead)
* Did not test detached attachments
Flags: needinfo?(neil)

    
    

    
  
Hello Mozilla Team,
Any news about this report?

    
    

    
  
Neil, is there someone who can review the patch or do we want to get a different patch for this issue?
Flags: needinfo?(neil)

    
    

    
  
(In reply to Al Billings from comment #17)
> Neil, is there someone who can review the patch or do we want to get a
> different patch for this issue?

You would need to start by finding a docshell peer to review the second half of the patch. Should that be accepted, a Thunderbird peer would then review the first half.
Flags: needinfo?(neil)

    
    

    
  
Comment on attachment 8466827 [details] [diff] [review]
Potential approach

Olli, could you take a look at this?  Thanks.

        Attachment #8466827 -
        Flags: review?(bugs)

    
    

    
  
The docshell part looks odd. Why we want the 'else'? That means we don't always honor 
mAllowContentRetargeting, and such special case is just error prone.

    
    

    
  
And DocShell code is so complicated that I really wouldn't want to add any new special cases there. Features need to work consistently.

Maybe we need some other flag there to handle this case, but it is not quite clear to me
what the requirements are.

        Attachment #8466827 -
        Flags: review?(bugs) → review-

    
    

    
  
(In reply to Olli Pettay from comment #20)
> The docshell part looks odd. Why we want the 'else'? That means we don't
> always honor mAllowContentRetargeting, and such special case is just error prone.

Disallowing content retargeting fixes the Thunderbird bug, but breaks certain cases involving LOAD_LINK (sorry I don't remember the exact details offhand). Making LOAD_LINK bypass that fixes those cases.

The one existing consumer doesn't use LOAD_LINK so they aren't affected.

    
    

    
  
Is there a way forward?
Flags: needinfo?(neil)
Flags: needinfo?(bugs)

    
    

    
  
Boris, did you say recently that you might be able to help on some Thunderbird security bugs? Can you look at this one?
Flags: needinfo?(bzbarsky)

    
    

    
  
Why can thunderbird not have a content policy that blocks TYPE_SUBDOCUMENT loads for such URIs?
Flags: needinfo?(bzbarsky)

    
    

    
  
(In reply to Boris Zbarsky from comment #25)
> Why can thunderbird not have a content policy that blocks TYPE_SUBDOCUMENT
> loads for such URIs?

We can't readily tell the content type of the URI so we'd basically have to indiscriminately block all frames in messages. (This would be a problem if seamless iframes ever became a thing because we want to use them for displaying inline message parts.)
Flags: needinfo?(neil)

    
    

    
  
I'm not sure I follow.  Why is the content type (of the thing that will load from the URI?) relevant?  I thought the issue was that simply running the imap:// URL caused problems?
Flags: needinfo?(bugs)

    
    

    
  
(In reply to Boris Zbarsky from comment #27)
> I'm not sure I follow.  Why is the content type (of the thing that will load
> from the URI?) relevant?  I thought the issue was that simply running the
> imap:// URL caused problems?

What do you mean be "the imap:// URL"? The message and all attachments and embedded objects have imap URLs, and I don't know how to tell which ones are safe just from the URL alone. (Maybe someone else does.)

    
    

    
  
OK, that matches my understanding.  So we'd need to block iframes pointing to imap:// urls, but you could still have a data: iframe.

Let's posit that we want a better solution, fine.

I'd like to be clearer on why DONT_RETARGET helps.  Is the issue that we end up with a MIME type we can't handle and then start looking for a different handler for it and that handler is what does the undesirable IMAP accesses?

    
    

    
  
(In reply to Boris Zbarsky from comment #29)
> OK, that matches my understanding.  So we'd need to block iframes pointing
> to imap:// urls, but you could still have a data: iframe.
No; as I understand it, some imap:// urls are safe (ones with a type parameter are more likely to be unsafe).

> I'd like to be clearer on why DONT_RETARGET helps.  Is the issue that we end
> up with a MIME type we can't handle and then start looking for a different
> handler for it and that handler is what does the undesirable IMAP accesses?
My understanding is that the potential to execute the handler is what is undesirable.

    
    

    
  
> No; as I understand it, some imap:// urls are safe 

Right, but we can't tell up front.

> My understanding is that the potential to execute the handler is what is undesirable.

OK.  So this is not about something the protocol handler does, but about some nsIContentHandler or nsIURIContentListener?

The earlier patch in this bug is not making sense to me; won't an <a href="imap://whatever-dangerous-url"> be just as bad?

    
    

    
  
(In reply to Boris Zbarsky from comment #31)
> The earlier patch in this bug is not making sense to me; won't an <a
> href="imap://whatever-dangerous-url"> be just as bad?

You might as well use <a href="http://whatever-dangerous-url"> - nothing will happen until the user clicks on it. This isn't true of an iframe.

    
    

    
  
Getting users to click a link is trivial.

    
    

    
  
(In reply to Boris Zbarsky from comment #33)
> Getting users to click a link is trivial.

Unfortunately getting users to open an executable attachment is quite easy too.

    
    

    
  
OK, fair.

But that said, are there actual use cases for <a href="imap://whatever">?  Comment 22 seems to claim there are, but I'd like to understand what they are, exactly.

    
    

    
  
(In reply to Boris Zbarsky from comment #35)
> But that said, are there actual use cases for <a href="imap://whatever">? 
> Comment 22 seems to claim there are, but I'd like to understand what they
> are, exactly.

Currently we simulate a link click to open an attachment which then uses the normal handler mechanism (this is application-dependent e.g. in SeaMonkey it opens a text attachment in the browser).

    
    

    
  
Simulate a link click in a subframe, though?  Or simulate a link click in the main mail docshell?

I guess your patch was setting retargeting to false on the messagepane itself.  Can we just set it to false on descendant docshells of the messagepane?

    
    

    
  
(In reply to Boris Zbarsky from comment #37)
> Simulate a link click in a subframe, though?  Or simulate a link click in
> the main mail docshell?
> 
> I guess your patch was setting retargeting to false on the messagepane
> itself.  Can we just set it to false on descendant docshells of the
> messagepane?

Sounds reasonable; I'd have to be able to set it early on in the frame's creation, so where would the best place be to handle that, back in the content policy again?

    
    

    
  
Do you have a custom treeowner here by any chance?

    
    

    
  
(In reply to Boris Zbarsky from comment #39)
> Do you have a custom treeowner here by any chance?

I didn't even know that was possible... I think we have the default content tree owner.

    
    

    
  
OK.  So we could add some sort of "hey, a docshell got created" notification.  Or we could add a new setter on docshell that doesn't set its retargeting stuff to false, but causes it to set retargeting stuff to false on all its kids.

The latter is probably simpler.

    
    

    
  
(In reply to Boris Zbarsky from comment #41)
> OK.  So we could add some sort of "hey, a docshell got created"
> notification.  Or we could add a new setter on docshell that doesn't set its
> retargeting stuff to false, but causes it to set retargeting stuff to false
> on all its kids.
> 
> The latter is probably simpler.

OK I'll work on the latter.

    
    

    
  

      
      
      
      

        Attached patch
          
          
        Patch as per comment #41 (obsolete)
        — 
          — Splinter Review
      

    


  

    
    

    
  
Hello mozilla security team,
I've reported this issue one year and one month ago to your bug bounty program.
Could you please tell me when this will be patched (I want to publish an article about this) and when the reward will be assigned?

Thank you,
LP

    
    

    
  
The patch is already over a month old.
Did you forget to set a review flag, Neil?
I'm not sure who to ask for a review, can you figure this out?
Assignee: nobody → neil
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Flags: needinfo?(neil)

    
    

    
  
(In reply to l.pontorieri from comment #44)
> Hello mozilla security team,
> I've reported this issue one year and one month ago to your bug bounty
> program.
> Could you please tell me when this will be patched (I want to publish an
> article about this) and when the reward will be assigned?
> 
> Thank you,
> LP

I'm terribly sorry, that this bug has been in limbo for so long :(
Thunderbird is maintained by community, so we can't really force this work upon someone specific ;-)

But I'll try to take this responsibility and poke a few more people about this.

    
    

    
  
Comment on attachment 8554272 [details] [diff] [review]
Patch as per comment #41

Olli said he can take a look.
Flags: needinfo?(neil)

        Attachment #8554272 -
        Flags: review?(bugs)

    
    

    
  
Comment on attachment 8554272 [details] [diff] [review]
Patch as per comment #41

> nsDocShell::SetAllowContentRetargeting(bool aAllowContentRetargeting)
> {
>+    mAllowContentRetargetingOnChildren =
>     mAllowContentRetargeting = aAllowContentRetargeting;

  mAllowContentRetargetingOnChildren = aAllowContentRetargeting;
  mAllowContentRetargeting = aAllowContentRetargeting;
Would be a tad easier to read.
And Docshell uses Mozilla coding style these days, so 2 spaces only.


>@@ -285,16 +285,22 @@ interface nsIDocShell : nsIDocShellTreeI
update uuid

This of course misses the TB specific part.

        Attachment #8554272 -
        Flags: review?(bugs) → review+

    
    

    
  


  

        Attachment #8554272 -
        Attachment is obsolete: true

        Attachment #8574381 -
        Flags: review?(bugs)

        Attachment #8574381 -
        Flags: review?(bugs) → review+
Flags: sec-bounty? → sec-bounty+

    
    

    
  
Any chance at a second checkin attempt soon? This thing is an ancient sec-high that comes up in Critsmash meetings.
Flags: needinfo?(neil)

    
    

    
  
https://hg.mozilla.org/integration/mozilla-inbound/rev/2232d2bce241

Sorry for the delay (combination of multiple tree closures and hard disk failure).
Flags: needinfo?(neil)

    
    

    
  
https://hg.mozilla.org/mozilla-central/rev/2232d2bce241
Status: ASSIGNED → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED

    
    

    
  
Bah, I forgot to set leave-open for the comm-central part of the patch.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---

    
    

    
  

      
      
      
      

        Attached patch
          
          
        comm-central part of patch (obsolete)
        — 
          — Splinter Review
      

    


  
(Haven't been able to find a reviewer for this patch yet.)

    
    

    
  
Comment on attachment 8584875 [details] [diff] [review]
comm-central part of patch

Review of attachment 8584875 [details] [diff] [review]:
-----------------------------------------------------------------

::: mailnews/base/src/nsMessenger.cpp
@@ +255,5 @@
>                                                 nullptr, nullptr, getter_AddRefs(childAsItem));
>  
>      mDocShell = do_QueryInterface(childAsItem);
>      if (NS_SUCCEEDED(rv) && mDocShell) {
> +      mDocShell->SetAllowContentRetargetingOnChildren(false);

Wouldn't this be better being set in nsMsgContentPolicy, e.g. in something like nsMsgContentPolicy::OnLocationChange ?

This would mean it'll be set correctly on whatever docshell is used for displaying messages.

    
    

    
  
(In reply to Mark Banner from comment #57)
> Wouldn't this be better being set in nsMsgContentPolicy, e.g. in something
> like nsMsgContentPolicy::OnLocationChange ?
> 
> This would mean it'll be set correctly on whatever docshell is used for
> displaying messages.

Good point, that would also stop it from affecting feed pages.

    
    

    
  


  

        Attachment #8584875 -
        Attachment is obsolete: true

        Attachment #8586460 -
        Flags: feedback?(standard8)

    
    

    
  
Comment on attachment 8586460 [details] [diff] [review]
Updated comm-central part of patch

I've not tested it, but I think this is the right place to set these, especially based on the other items there ;-)

        Attachment #8586460 -
        Flags: feedback?(standard8) → feedback+

    
    

    
  
So whom would you suggest to review attachment 8586460 [details] [diff] [review]?

    
    

    
  
Can you also do the actual review, Mark?
Flags: needinfo?(standard8)

    
    

    
  
Comment on attachment 8586460 [details] [diff] [review]
Updated comm-central part of patch

I tried reproducing the exploit to test this but wasn't able to, probably because I was missing something or on the wrong platform.

However, Neil tells me he has tested this, so I'm therefore giving this r+ based on his testing, and this looks like the right thing to do in the right place.
Flags: needinfo?(standard8)

        Attachment #8586460 -
        Flags: review+

    
    

    
  
Pushed comm-central changeset 6bd8cda9d3e3.
Status: REOPENED → RESOLVED
Closed: 8 years ago → 8 years ago
Keywords: leave-open
Resolution: --- → FIXED
Target Milestone: --- → Thunderbird 40.0

    
    

    
  
Could you assign a CVE id to this issue?

Thank you
OS: Linux → All
Hardware: x86 → All

    
    

    
  
What is the uplift plan for this to 38 and esr31?

    
    

    
  
CVE assigned.
Alias: CVE-2015-2707

    
    

    
  
(In reply to Kent James (:rkent) from comment #66)
> What is the uplift plan for this to 38 and esr31?

Someone needs to request approvals for both patches. I don't see an issue with uplifting to 38, especially as there's still a couple of weeks left in beta.

Not sure about 31. Someone needs to check the patches will apply & work correctly (I suspect they will, they seemed quite simple in code that's unlikely to have changed much), and then get approvals.

    
    

    
  
Neil, would you be able to request approval-mozilla-beta (along with the risk assessment) so that we can try to get this into gecko 38? I can handle the comm-beta part after the mozilla-beta part lands.
Flags: needinfo?(neil)

    
    

    
  
Comment on attachment 8574381 [details] [diff] [review]
Updated for review comments and bitrot

Approval Request Comment
[Risks and why]: Desired for Thunderbird ESR
[String/UUID change made/needed]: UUID change
Flags: needinfo?(neil)

        Attachment #8574381 -
        Flags: approval-mozilla-beta?

    
    

    
  
(In reply to Kent James from comment #69)
> the risk assessment

Oh, I forgot that bit, sorry.

    
    

    
  
I had not noticed the interface change.

What has been the approach to this in that past? That is, can we avoid the binary compatibility problem by creating a second interface that only includes the one added attribute? Or are changes like this typically accepted so late in beta?

    
    

    
  
(In reply to Kent James from comment #72)
> I had not noticed the interface change.
> 
> What has been the approach to this in that past? That is, can we avoid the
> binary compatibility problem by creating a second interface that only
> includes the one added attribute? Or are changes like this typically
> accepted so late in beta?

Yeah, I might be able to implement it as an nth interface,

        Attachment #8596137 -
        Flags: review?(bugs) → review+

    
    

    
  
Comment on attachment 8574381 [details] [diff] [review]
Updated for review comments and bitrot

As noticed, we cannot take it because of the uuid change.
Please resubmit for uplift the new patch with the uplift template filled.
Thanks

        Attachment #8574381 -
        Flags: approval-mozilla-beta? → approval-mozilla-beta-

    
    

    
  
Comment on attachment 8596137 [details] [diff] [review]
Branch-safe version of attachment 8574381 [details] [diff] [review]

Approval Request Comment
[Feature/regressing bug #]: N/A
[User impact if declined]: N/A
[Describe test coverage new/current, TreeHerder]: Not used by Firefox
(Trunk patch has baked for a month on central/aurora without issues)
[Risks and why]: Needed by Thunderbird
[String/UUID change made/needed]: None

        Attachment #8596137 -
        Flags: approval-mozilla-beta?

    
    

    
  
Comment on attachment 8596137 [details] [diff] [review]
Branch-safe version of attachment 8574381 [details] [diff] [review]

Taking it because 38 is an ESR, it is a sec high and it is the base of TB.

        Attachment #8596137 -
        Flags: approval-mozilla-beta? → approval-mozilla-beta+

    
    

    
  
Comment on attachment 8596137 [details] [diff] [review]
Branch-safe version of attachment 8574381 [details] [diff] [review]

[Triage Comment]
38 is now in m-r.

        Attachment #8596137 -
        Flags: approval-mozilla-beta+ → approval-mozilla-release+

    
    

    
  
Shouldn't this also go to mozilla-esr31?

    
  

          status-thunderbird38:
          fixed → affected

          status-thunderbird39:
          fixed → affected

          status-thunderbird40:
          --- → fixed
Target Milestone: Thunderbird 39.0 → Thunderbird 40.0

    
    

    
  


  

        Attachment #8597597 -
        Flags: review?(rkent)

    
  

        Attachment #8597597 -
        Flags: review?(rkent) → review+

    
    

    
  
Comment on attachment 8597597 [details] [diff] [review]
Branch version of attachment 8586460 [details] [diff] [review]

[Triage Comment]

        Attachment #8597597 -
        Flags: approval-comm-beta+

        Attachment #8597597 -
        Flags: approval-comm-aurora+

    
    

    
  
It looks like the mozilla branch patch did not land in mozilla-aurora, so the status-firefox39 is incorrect?

    
    

    
  
Comment on attachment 8586460 [details] [diff] [review]
Updated comm-central part of patch

(In reply to Kent James from comment #86)
> It looks like the mozilla branch patch did not land in mozilla-aurora, so
> the status-firefox39 is incorrect?

The mozilla trunk patch landed last month, so it got automatically uplifted to mozilla-aurora*. This means that it is this patch that you would need for comm-aurora.

* http://hg.mozilla.org/releases/mozilla-aurora/rev/2232d2bce241

        Attachment #8586460 -
        Flags: approval-comm-aurora?

    
    

    
  
I assume that this isn't fixed in the upcoming Thunderbird release since that is built off of ESR31 and we didn't fix this there. So, effectively this didn't get fixed in Thunderbird. Do I misunderstand?
Flags: needinfo?(neil)
Flags: needinfo?(ludovic)

    
    

    
  
(In reply to Al Billings from comment #88)
> I assume that this isn't fixed in the upcoming Thunderbird release since
> that is built off of ESR31 and we didn't fix this there. So, effectively
> this didn't get fixed in Thunderbird. Do I misunderstand?

ESR31 is affected because neither has attachment 8596137 [details] [diff] [review] been uplifted to mozilla-esr31 nor attachment 8597597 [details] [diff] [review] to comm-esr31.
39 is affected because attachment 8586460 [details] [diff] [review] has not been uplifted to comm-aurora.
ESR38, 38 and 40 should be fixed.
Flags: needinfo?(neil)

    
    

    
  
(In reply to neil@parkwaycc.co.uk from comment #89)

> ESR31 is affected because neither has attachment 8596137 [details] [diff] [review]
> [review] been uplifted to mozilla-esr31 nor attachment 8597597 [details] [diff] [review]
> [diff] [review] to comm-esr31.
> 39 is affected because attachment 8586460 [details] [diff] [review] has not
> been uplifted to comm-aurora.
> ESR38, 38 and 40 should be fixed.

Well, that means shipping Thunderbird is affected because we don't ship TB 38 (or 39 or 40). Public TB builds are all based on ESR31. So, basically, we didn't fix it for TB in the one branch we ship...
Flags: needinfo?(ludovic)
Whiteboard: [reporter-external] → [reporter-external][adv-main38-]

    
    

    
  
Comment on attachment 8586460 [details] [diff] [review]
Updated comm-central part of patch

[Triage Comment]

http://hg.mozilla.org/releases/comm-beta/rev/ae46efbe3a5b

        Attachment #8586460 -
        Flags: approval-comm-aurora? → approval-comm-beta+

    
  
Group: core-security → core-security-release
Group: core-security-release

          You need to log in
          before you can comment on or make changes to this bug.