1015636 - (CVE-2014-1535) pdfjs privilege escalation round 2

Status: RESOLVED FIXED

(Firefox :: PDF Viewer, defect)

Description

[Cody Crews]

Attachment: pdfPluginRound2-testcase-new.html

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:29.0) Gecko/20100101 Firefox/29.0 (Beta/Release)
Build ID: 20140506152807

Steps to reproduce:

I created an embed object to load the pdfjs implementation as a plugin and then used setTimeout(pseudo race condition) to load a privileged xul document.


Actual results:

Even though the window isn't actually visible a chrome URI xul document is loaded and can be accessed as a sub-frame of the content window by doing window[0].


Expected results:

I should have received an exception since once again this is loading data of a type that is not expected.  I think this one slipped through the cracks before because I used an iframe to do this.  This time its the actual anonymous iframe that's a child of the embed element doing the work.

Comment 1

[Cody Crews]

Script injection could surely be obtained here with the right work.  I found this late yesterday evening.  I'll see what I can do between today and tomorrow but don't expect much more time for this one.  I have to stress that I'm on linux primarily and haven't testing this in windows but it works in the currently release up to the newest nightly so I'm sure it's there too.  I have some other work that's close to getting nasty that I think I'll probably prioritize over this.

Comment 2

[Cody Crews]

Lol I'm pretty bad ;-)

testing should be tested and currently should be current.  Ever since I dropped most of my meds(some for ADD) that's only getting worse.  My fingers are outrunning my mind! 

Anyway I have so other work that's close to the level to be concerned about but I'm going to enjoy the rest of this leisurely weekend.  Later guys probably Tuesday before I'm back around.

Comment 3

[Cody Crews]

Thought I would leave a note here while I have the chance.  If this isn't working for someone then adjust the value in the call to setTimeout.  10 is the value that works most reliably on my system.  Like I said I would consider this a 'pseudo race condition' for what its worth.  I'll be in touch.

Comment 4

[Bobby Holley (:bholley)]

Can someone familiar with pdf.js take a look here?

Comment 5

[Yury Delendik (:yury)]

The src property is read here via srcURI at
http://mxr.mozilla.org/mozilla-central/source/browser/extensions/pdfjs/content/PdfRedirector.jsm#69 . I'm sure how it's related to pdf.js at this point yet. Does the object shall destroy its overlay when src is changed?

Comment 6

[Cody Crews]

That might should be the case, the funny part is that if you have the browser console open you will see a security error, but I assume that its thrown from the content page actually setting the src attribute of the embed.  Essentially all this is doing is immediately changing the src attribute of the embed attribute before it actually starts to load data in PdfRedirector.jsm mentioned above.  I thought I would play with the idea and actually was surprised when I saw it work ;-)

Comment 7

[Yury Delendik (:yury)]

Does `embed.src = 'chrome://browser/content/browser.xul';` work as well?

Comment 8

[Cody Crews]

Do you mean in the setTimeout call or does just setting it before appending to the document work?  There's definitely a security check if you set the src to the embed then append it to the document, but using that in a call to setTimeout might work I haven't tested.  This one is iffy either way sometimes even I don't get the chrome xul document loaded as a sub-frame of the window.  The issue is there, its just all about the timing which would be different for any system.  Setting the type of the embed is a must too.  An ideal testcase would use different timings and catch errors while trying to access properties of the frame that gets loaded until by catching an error it would know that the timing was right.

Comment 9

[Yury Delendik (:yury)]

I was unable to replicate and have question about "can be accessed as a sub-frame of the content window by doing window[0]." part. Could you expand the test with example that demonstrate the complete attack? Also, do you have to have a native PDF plugin installed?

Comment 10

[Cody Crews]

I'm not sure how its hard to understand.  This works in the newest release up to the newest nightly, if you see the embed overlay load check window[0].  This would normally be a sub-frame of whatever you loaded as a plugin but instead will appear as [Object object].  If you use console.log or the browser console you will see it is a window containing a chrome xul document.  If a better testcase is needed(which im not sure why) I'll put one together.

Comment 11

[Yury Delendik (:yury)]

> If a better testcase is needed(which im not sure why) I'll put one together.

Yes please

Comment 12

[Cody Crews]

Should note too that with the attachment you may need to reload it once to see the embed overlay(I just tested it)

Comment 13

[Cody Crews]

I have to ask before breaking this down and rewriting it(which will only take a minute) are you actually getting the embed overlay rendered?  On my system with the timing of 10 miliseconds if you get the overlay rendered then it worked.  Let me get to this revised testcase.

Comment 14

[Cody Crews]

Attachment: pdfPluginRound2-testcase-revision.html

This should take care of the timing and once finished log the window with the chrome xul document into your console.  Once you see the embed overlay just ctrl+shift+k and the window with a chrome URI should be looking at you.  Let me know if this one doesn't work for anyone, but I am doubtful about that.

Comment 15

[John Schoenick [:johns]]

Running in debug with with NSPR_LOG_MODULES=objlc:5 shows the object element is doing the expected thing:

> OBJLC [7fffb8405e70]: LoadObject called, notify 1, forceload 0, channel 0
> OBJLC [7fffb8405e70]: Updating object parameters
> OBJLC [7fffb8405e70]: Channel parameters changed
> OBJLC [7fffb8405e70]: Type changed from 0 -> 4
> OBJLC [7fffb8405e70]: Object effective baseURI changed
> OBJLC [7fffb8405e70]: Object effective mime type changed ( -> application/pdf)
> OBJLC [7fffb8405e70]: LoadObject - plugin state changed (7)
> OBJLC [7fffb8405e70]: Marking plugin as click-to-play
> OBJLC [7fffb8405e70]: Loading fallback, type 11
> OBJLC [7fffb8405e70]: Notifying about state change: (0, 400000) -> (4, 100000000000) (sync 0, notify 1)
> OBJLC [7fffb6fff400]: Unloading plugin outside of document
> OBJLC [7fffb8405e70]: LoadObject called, notify 1, forceload 1, channel 0
> OBJLC [7fffb8405e70]: Updating object parameters
> OBJLC [7fffb8405e70]: Channel parameters changed
> OBJLC [7fffb8405e70]: Type changed from 4 -> 0
> OBJLC [7fffb8405e70]: Object effective URI changed
> OBJLC [7fffb8405e70]: LoadObject - plugin state changed (3)
> OBJLC [7fffb8405e70]: OpenChannel returned failure (2152924148)
> OBJLC [7fffb8405e70]: Loading failed, switching to fallback
> OBJLC [7fffb8405e70]: Loading fallback, type 1
> OBJLC [7fffb8405e70]: Notifying about state change: (4, 100000000000) -> (4, 80000) (sync 0, notify 1)

I'm guessing what's happening is the fallback content causes layout to bind a XBL frame at some point, but since XBL bindings/layout are async, the srcURI is different by time the pdf.js handler gets to it?

I think we should not be using the same URL [1] For various fallback types, to ensure the frame gets re-created if fallback changes. Normally this would only cause the wrong fallback error message to appear, but playPreview content is potentially doing chrome-y things and assuming whatever it was bound for is security checked.

pdf.js should check that the plugin tag is still in playPreview mode for a pdf when it attempts to load, then, to prevent unwanted racing. Longer term, the jsplugins api in bug 558184 should remove our dependence on the XBL cludge.

[1] http://dxr.mozilla.org/mozilla-central/source/toolkit/mozapps/plugins/content/pluginProblemBinding.css#31

Comment 16

[Cody Crews]

Whats wrong with code in pdfRedirector.jsm checking the mimetype of the data that is actually being loaded and bailing out if its not application/pdf?  That would be a very minimal change imo(possibly a few lines of code) and then more long term solutions could be thought out.  My point in thinking along these lines is by the time any code in pdfRedirector.jsm is touched either a pdf document is being loaded or someone is being funny.  It's on you guys either way and I'm not that good with coding just a hacker tinkering with things ;-)

Comment 17

[Yury Delendik (:yury)]

Attachment: PdfRedirector checks if plugin is still in PlayPreview mode

(In reply to John Schoenick [:johns] from comment #15)
> pdf.js should check that the plugin tag is still in playPreview mode for a
> pdf when it attempts to load, then, to prevent unwanted racing.

Comment 18

[John Schoenick [:johns]]

Comment on attachment 8429604 [details] [diff] [review]
PdfRedirector checks if plugin is still in PlayPreview mode

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

::: browser/extensions/pdfjs/content/PdfRedirector.jsm
@@ +42,5 @@
>    return win;
>  }
>  
>  function getObjectUrl(window) {
> +  var PLAY_PREVIEW = 11;

I think just |element.pluginFallbackType !== element.PLAY_PREVIEW| will work here, since it's a const in the MozObjectLoadingContent interface, so you don't have to hard-code the constant.

Comment 19

[Yury Delendik (:yury)]

Attachment: PdfRedirector checks if plugin is still in PlayPreview mode

Comment 20

[Yury Delendik (:yury)]

Comment on attachment 8429688 [details] [diff] [review]
PdfRedirector checks if plugin is still in PlayPreview mode

[Security approval request comment]
How easily could an exploit be constructed based on the patch?

Do comments in the patch, the check-in comment, or tests included in the patch paint a bulls-eye on the security problem?

Which older supported branches are affected by this flaw?

If not all supported branches, which bug introduced the flaw?

Do you have backports for the affected branches? If not, how different, hard to create, and risky will they be?

How likely is this patch to cause regressions; how much testing does it need?

Comment 21

[John Schoenick [:johns]]

Comment on attachment 8429688 [details] [diff] [review]
PdfRedirector checks if plugin is still in PlayPreview mode

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

::: browser/extensions/pdfjs/content/PdfRedirector.jsm
@@ +59,5 @@
>      tagName = element.nodeName;
>    }
>  
>    // Checking if overlay is a proper PlayPreview overlay.
> +  if (element.pluginFallbackType !== element.PLUGIN_PLAY_PREVIEW) {

Actually, to be thorough, let's do:
> element.displayedType !== element.TYPE_NULL || element.pluginFallbackType !== element.PLUGIN_PLAY_PREVIEW

Since I'm not 100% sure we always clear the fallback type field when we change type to non-fallback. r=me with that

Comment 22

[Andrew McCreight [:mccr8]]

How exploitable do you think this is?  eg what sort of rating should we give this.

Comment 23

[Yury Delendik (:yury)]

(In reply to Andrew McCreight [:mccr8] from comment #22)
> How exploitable do you think this is?  eg what sort of rating should we give
> this.

I would assign the same rating as in bug 920515. The full exploit can be found in the attachment 8429537 [details] above.

Comment 24

[Andrew McCreight [:mccr8]]

Thanks.

Comment 25

[Yury Delendik (:yury)]

Attachment: PdfRedirector checks if plugin is still in PlayPreview mode (for FF30+)

[Security approval request comment]
How easily could an exploit be constructed based on the patch?

Not sure. Might be easy if it will associated with CVE-2013-5598 description. 

Do comments in the patch, the check-in comment, or tests included in the patch paint a bulls-eye on the security problem?

Comments just provide shallow description of what the new code is doing.

Which older supported branches are affected by this flaw?

esr24? 

If not all supported branches, which bug introduced the flaw?

see bug 920515 (and original bug 738967)

Do you have backports for the affected branches? If not, how different, hard to create, and risky will they be?

PdfRedirector.jsm was moved in version 30 from different folder, but the code is identical to the code after bug 920515 fix.

How likely is this patch to cause regressions; how much testing does it need?

There is low risk that the patch will cause the regression. Also, as I understand, there is a very low number of web sites are using EMBED tag to embed PDFs (primary use case does not involve PdfRedirector.jsm).

Comment 26

[Cody Crews]

I just found out that this could be more dangerous than it seems at first.  If you change the location of the chrome privileged window to one accessible from content it allows one to hold a reference to its eval function.  With this reference ready you can call the back function of that window reloading the chrome URI and then when accessing navigator.mozApps the mgmt property is available.  Now just to set some of those event handlers and hmm.  Hopefully this is taken care of here because I could see that leading chrome level code execution, not entirely sure though.  Either way its definitely something to keep an eye out for in the future.  Maybe navigator.mozApps needs reworking of its principal management?  The immediate problem I see with this is any dom request objects returned are not accessible.

Comment 27

[Daniel Veditz [:dveditz]]

Comment on attachment 8430473 [details] [diff] [review]
PdfRedirector checks if plugin is still in PlayPreview mode (for FF30+)

sec-approval+

Please land on all the branches (aurora, beta, esr-24) today: the release RC goes out to the beta channel on Monday morning. Normally the sheriffs can help you land but you mention code drift so you'll need the updated patches for the old branches.

Does b2g support pdfjs yet? We may need those branches, too.

Comment 28

[Yury Delendik (:yury)]

Attachment: valid usage of embed tag

normal usage of the embed tag (for testing of the regression)

Comment 29

[Yury Delendik (:yury)]

(In reply to Daniel Veditz [:dveditz] from comment #27)
> Does b2g support pdfjs yet? We may need those branches, too.

pdf.js integration using embed tag with desktop version of Firefox is at fault here, not pdf.js itself. b2g uses different type of integration (via activitities), therefore cannot be affected.

Comment 30

[Yury Delendik (:yury)]

Attachment: PdfRedirector checks if plugin is still in PlayPreview mode (for ESR24)

Comment 31

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-aurora/rev/3c82cb80cda6
https://hg.mozilla.org/releases/mozilla-beta/rev/df3506c7ad59
https://hg.mozilla.org/releases/mozilla-esr24/rev/a8859c69b2a5

This will be fixed on trunk via bug 1018999, which was just pushed to fx-team.

Comment 32

[Cody Crews]

whats the status of the bug bounty here?  I thought I would know something by now :-)

Comment 33

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-b2g30_v1_4/rev/df3506c7ad59

Comment 35

[Liz Henry (:lizzard) (relman/hg->git project)]

Matt, is this something that you end up verifying? Is this something that should get uplifted?

Comment 36

[Matt Wobensmith [:mwobensmith][:matt:]]

(In reply to Liz Henry :lizzard from comment #35)
> Matt, is this something that you end up verifying? Is this something that
> should get uplifted?

Yes and yes. We'll do the verification shortly.

Comment 37

[Matt Wobensmith [:mwobensmith][:matt:]]

Fixed on Fx30, 2014-06-03.

However, this still appears to be broken on release candidate of Fx24.6.0esr. The chrome page is displayed in the iframe. Yury, can you take a look?

http://ftp.mozilla.org/pub/mozilla.org/firefox/candidates/24.6.0esr-candidates/build1/

Comment 38

[Yury Delendik (:yury)]

(In reply to Matt Wobensmith from comment #37)
> However, this still appears to be broken on release candidate of
> Fx24.6.0esr. The chrome page is displayed in the iframe. Yury, can you take
> a look?

Matt, are you talking about pdf from "valid usage of embed tag" not showing in the viewer or "pdfPluginRound2-testcase-revision.html" showing signs not to be fixed?

If first case, the attachment might not be shown due to bug in pdf.js and not relevant to this issue -- was the same page showing fine prior Fx24.6.0esr?

Comment 39

[Matt Wobensmith [:mwobensmith][:matt:]]

Hi Yury, apologies, I should have been more clear.

Using both of the two attachments codyc submitted, I can still see the embedded chrome page in the iframe, using release candidate of Fx24.6.0esr.

The same test cases when viewed in today's Fx30 just reload the page indefinitely, but never load the iframe/chrome page. 

I assume that - to verify this as fixed - we want to make sure that this iframe does not load. Does that sound correct?

Comment 40

[Yury Delendik (:yury)]

Matt, I cannot replicate the issue. Do you have pdf.js add-on installed? Can you also check it with new profile?

Comment 41

[Yury Delendik (:yury)]

On Matt's computer Fx24.6.0esr still loads the chrome iframe. I cannot reproduce it locally neither on Fx24.6.0esr candidate nor on custom 24ESR builds.

John, do you think it's the timing or something in nsIObjectLoadingContext is not working the same way in FF24?

Comment 42

[Cody Crews]

(In reply to Yury Delendik (:yury) from comment #41)
> On Matt's computer Fx24.6.0esr still loads the chrome iframe. I cannot
> reproduce it locally neither on Fx24.6.0esr candidate nor on custom 24ESR
> builds.
> 
> John, do you think it's the timing or something in nsIObjectLoadingContext
> is not working the same way in FF24?

This is kind of worrisome to me.  My system isn't top notch so there could be timings smaller than 10 that can trigger this, also a system much more powerful than mine may gain an extra chance or two on the race.  If you guys don't mind, let me know what you find out.

Comment 43

[Kamil Jozwiak [:kjozwiak]]

Reproduced the original issue on OSX 10.9.3 using the following build:
- http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2014-05-24-03-02-04-mozilla-central/
- http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2014-05-24-00-40-02-mozilla-aurora/
- http://ftp.mozilla.org/pub/mozilla.org/firefox/releases/30.0b7/mac/en-US/

- Opened the revised test case from comment # 14
- Opened the console, following text is visible: Window → chrome://browser/content/browser.xul"
- Typed in window[0], received: Object → chrome://browser/content/browser.xul

Verified using the following builds:
- http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2014-06-05-03-02-02-mozilla-central/
- http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2014-06-05-00-40-02-mozilla-aurora/

- Opened the revised test case from comment # 14
- Console appeared blank
- Typed in window[0], received: Window → about:blank

With ESR, rather than receiving "Window → chrome://browser/content/browser.xul" under the the console, I received the following:
- Typed in window[0], received: [object Object]

Used the following builds for the above ESR tests:

- http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2014-05-23-00-05-02-mozilla-esr24/
- http://ftp.mozilla.org/pub/mozilla.org/firefox/candidates/24.6.0esr-candidates/build1/mac/en-US/

It seems that nothing has changed under ESR and "[object Object]" is still appearing under "window[0]". Shouldn't we be receiving "Window → about:blank" with the 24.6.0.esr candidate? (same behaviour as in fx 31, fx 32?)

I never received an embedded page while testing this so I used the above method which seems to have worked under fx31 & fx32. If this is a valid way of testing, those two can be marked as verified. ESR seems to still be loading [object Object] when typing in window[0] as mentioned above and in comment # 10.

Comment 44

[Cody Crews]

(In reply to Kamil Jozwiak [:kjozwiak] from comment #43)
> Reproduced the original issue on OSX 10.9.3 using the following build:
> -
> http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2014-05-24-03-02-04-
> mozilla-central/
> -
> http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2014-05-24-00-40-02-
> mozilla-aurora/
> - http://ftp.mozilla.org/pub/mozilla.org/firefox/releases/30.0b7/mac/en-US/
> 
> - Opened the revised test case from comment # 14
> - Opened the console, following text is visible: Window →
> chrome://browser/content/browser.xul"
> - Typed in window[0], received: Object → chrome://browser/content/browser.xul
> 
> Verified using the following builds:
> -
> http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2014-06-05-03-02-02-
> mozilla-central/
> -
> http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2014-06-05-00-40-02-
> mozilla-aurora/
> 
> - Opened the revised test case from comment # 14
> - Console appeared blank
> - Typed in window[0], received: Window → about:blank
> 
> With ESR, rather than receiving "Window →
> chrome://browser/content/browser.xul" under the the console, I received the
> following:
> - Typed in window[0], received: [object Object]
> 
> Used the following builds for the above ESR tests:
> 
> -
> http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2014-05-23-00-05-02-
> mozilla-esr24/
> -
> http://ftp.mozilla.org/pub/mozilla.org/firefox/candidates/24.6.0esr-
> candidates/build1/mac/en-US/
> 
> It seems that nothing has changed under ESR and "[object Object]" is still
> appearing under "window[0]". Shouldn't we be receiving "Window →
> about:blank" with the 24.6.0.esr candidate? (same behaviour as in fx 31, fx
> 32?)
> 
> I never received an embedded page while testing this so I used the above
> method which seems to have worked under fx31 & fx32. If this is a valid way
> of testing, those two can be marked as verified. ESR seems to still be
> loading [object Object] when typing in window[0] as mentioned above and in
> comment # 10.

[object Object] is no good.  It probably means that its a window that you don't have access to ie a chrome URI window.  This might still be an issue for ESR builds then?

Comment 45

[Cody Crews]

I can confirm that this bug is still there in the 24.5.0 ESR builds.  Is this supposed to be fixed here?  If not direct me to the build that's supposed to be fixed and I'll test.

Comment 46

[Cody Crews]

Hmm, this is very interesting.   I don't get anything except a window with the URI "about:blank" in the 24.6.0 ESR builds.  Is anyone else still experiencing this bug on 24.6.0 ESR?

Comment 47

[Matt Wobensmith [:mwobensmith][:matt:]]

(In reply to codyc from comment #46)
> Hmm, this is very interesting.   I don't get anything except a window with
> the URI "about:blank" in the 24.6.0 ESR builds.  Is anyone else still
> experiencing this bug on 24.6.0 ESR?

The 24.5.0 ESR build doesn't have the fix; the 24.6.0 ESR build does. We appear to be still having an issue with the latter.

Build is here:
http://ftp.mozilla.org/pub/mozilla.org/firefox/candidates/24.6.0esr-candidates/build1/

Comment 48

[Cody Crews]

Yeah same result as the 24.6.0 I just tested.  The window appears but is always accessible which keeps the loop of the race attempt going.  I even tested breaking down the timing manually and trying different extremes of values and still get nothing but a window pointing to "about:blank"

I guess this is why race type situations can be so interesting.  The issue would really come in play with the ESR build being deployed on systems that just happen to somehow get the timing right(a lot of the same machines), that could leave some institutions wide open to attack.  I definitely can't reproduce this locally though.

Comment 49

[John Schoenick [:johns]]

So, I'm confused here. Why is window[0] being filled in the first place? Is this being done specifically by pdf.js, or is this some iframe in the XBL scope visible to content?

In ESR24, on "Valid usage of the embed tag", I get window[0] -> [object Object] that throws a permissions error on access of location.href. I get the same thing on nightly, except I see "Object → https://bug871202.bugzilla.mozilla.org/attachment.cgi".

Then, on the test case, in ESR24, I just get window[0] -> undefined. I haven't seen an about:blank anywhere. In all cases, the NSPR_LOG_MODULES=objlc:5 output looks normal, loading one fallback and then another, where the race condition appears to be for handlers attaching to the pluginProblemBinding.

Comment 50

[Cody Crews]

window[0] is being filled either way because there is an anonymous iframe that is part of the embed overlay that is used to preview plugin content.  If the race doesn't work the window that would normally be a chrome URI window is instead of normal content level window with location.href == "about:blank"

The race is setup so that it checks for an error while access window[0].location.href and IF it gets an error then it is assumed that it has become a privileged window and that access to location.href is no longer available for that window.

When the race condition doesn't work it just reloads the embed overlay every half a second.  There is a window there for me when it doesn't work with the location of "about:blank"

This one is a real mess apparently.

Comment 51

[Cody Crews]

(In reply to John Schoenick [:johns] from comment #49)
> So, I'm confused here. Why is window[0] being filled in the first place? Is
> this being done specifically by pdf.js, or is this some iframe in the XBL
> scope visible to content?

This could be worrisome too.

Comment 52

[Al Billings [:abillings - ex-MoCo]]

(In reply to codyc from comment #48)
> Yeah same result as the 24.6.0 I just tested.  The window appears but is
> always accessible which keeps the loop of the race attempt going.  I even
> tested breaking down the timing manually and trying different extremes of
> values and still get nothing but a window pointing to "about:blank"

This makes it sound like this issue isn't fixed in the ESR release next week. Can someone verify this? Does the actual exploit still work? This is a bad sec-high.

Comment 53

[Matt Wobensmith [:mwobensmith][:matt:]]

Al, I think we need to hold off on the advisory, as we still feel it's unresolved for ESR.

Comment 54

[Kamil Jozwiak [:kjozwiak]]

Agreed, while going through this in comment # 43, it didn't seem like it was fixed in ESR.

Comment 55

[Yury Delendik (:yury)]

Al, I'm not sure what's going on with ESR since I cannot replicate it locally. I'll keep digging.

I can disable support of the EMBED tag support for ESR (and even for Firefox 30+) for now.

Comment 56

[Yury Delendik (:yury)]

Attachment: Disables EMBED tag support for 'application/pdf'

Comment 57

[Al Billings [:abillings - ex-MoCo]]

(In reply to Matt Wobensmith from comment #53)
> Al, I think we need to hold off on the advisory, as we still feel it's
> unresolved for ESR.

No, generally we remove ESR from the advisory (since it is fixed on 30) and move forward. There are a number of bugs that don't get ported to ESR that we still do advisories for.

Comment 58

[Matt Wobensmith [:mwobensmith][:matt:]]

(In reply to Al Billings [:abillings] from comment #57)
> (In reply to Matt Wobensmith from comment #53)
> > Al, I think we need to hold off on the advisory, as we still feel it's
> > unresolved for ESR.
> 
> No, generally we remove ESR from the advisory (since it is fixed on 30) and
> move forward. There are a number of bugs that don't get ported to ESR that
> we still do advisories for.

Understood.

In this case, I think we do intend to port this to ESR. After it lands, and we release, will we issue a separate advisory?

Comment 59

[Al Billings [:abillings - ex-MoCo]]

(In reply to Matt Wobensmith from comment #58)

> In this case, I think we do intend to port this to ESR. After it lands, and
> we release, will we issue a separate advisory?

No, I'll just update the existing advisory to reflect that it has been fixed in ESR.

Comment 60

[Cody Crews]

(In reply to Yury Delendik (:yury) from comment #56)
> Created attachment 8435920 [details] [diff] [review]
> Disables EMBED tag support for 'application/pdf'

Looking through the changes here it seems that you're totally removing 'application/pdf' support from plugins.  I'll assume that is going to handle object tags too.  I was worried for a second when I saw the EMBED tag part.

I'll be doing some more testing in this area this weekend and come back with any remaining issues I can find.

Comment 61

[moz_bug_r_a4]

I have a testcase that works without depending on the timing.  I'll attach it although I'm not sure whether it might be helpful in investigating the remaining issue on ESR24.

Comment 62

[moz_bug_r_a4]

Attachment: testcase (no race)

With this testcase, I can reproduce the bug (the chrome page is loaded in the iframe) on fx29 and fx24.5.0esr, but I cannot reproduce it on fx30 and fx24.6.0esr.

Comment 63

[Cody Crews]

(In reply to moz_bug_r_a4 from comment #62)
> Created attachment 8436462 [details]
> testcase (no race)
> 
> With this testcase, I can reproduce the bug (the chrome page is loaded in
> the iframe) on fx29 and fx24.5.0esr, but I cannot reproduce it on fx30 and
> fx24.6.0esr.

Hmm so apparently bug 920515 was never fully taken care of.  If you haven't seen it, check it out. Originally I triggered the loading of local file system files by changing the location of the window created by the anonymous iframe just as you're doing here.  I think disabling 'application/pdf' for plugins is probably the right move for now because this is all a mess, and I believe I'm close to having something else come together based on this.

Comment 64

[moz_bug_r_a4]

Could you please cc me on bug 920515?

Comment 65

[Bobby Holley (:bholley)]

Actually, I think we should embargo this until bug 1022919 and bug 558184 are sorted out.

Comment 66

[Al Billings [:abillings - ex-MoCo]]

Agreed. I've pulled the advisory.

Comment 67

[Matt Wobensmith [:mwobensmith][:matt:]]

If this bug was not fixed on Fx24esr, should related bug 1022919 be tracked for that branch?

Comment 68

[u279076]

Matt, if you get a moment could you please verify this fixed for Firefox 31 and 32?

Comment 69

[Matt Wobensmith [:mwobensmith][:matt:]]

I re-ran these bug files on three Mac systems (10.7.5, 10.9.3, 10.9.4) and one Windows 8.1 system.

I am finding that - for me - all branches are fine on everything except Mac OSX 10.9.x. For the two systems that I have there, all branches fail. The chrome page loads always.

This conflicts with my previous finding for Fx30 (comment 37) and differs from Kamil's findings in comment 43.

In any case, I have two systems that fail consistently, correlated by that OS. From this end, the bug just doesn't appear fixed consistently at all, and it could be specific to that OS version.

Comment 70

[Cody Crews]

There's definitely more to this, I cannot reproduce the race condition after the fix here, but I have found a way yet again to get this to do something nasty.  Local file disclosure and a way to load partially privileged windows, I consider it myself to be a separate bug(bypassing a plugin type fallback/change) that should be taken care of by bug 1022919.  I'll file a new bug with a testcase sometime this weekend, but we definitely need to be more in depth with everything that relates to this.  I took a lengthy break around the fourth and still haven't exactly caught up to everything so forgive me if I don't get to it until Monday.  There's other issues I've found that I need to do testcases for and get filed, so if I get the chance I'll definitely jump on it.