User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:39.0) Gecko/20100101 Firefox/39.0 Build ID: 20150629114049 Steps to reproduce: Summary: I was visiting a news website when some ad script ran and injected an iframe that used PDF.JS's viewer.js to access files on my system (Possible Same Origin Policy bypass?). It triggered an error in view.js that I could view in the Firefox Developer Tools: "An error occurred while loading the PDF. PDF.js v1.1.24 (build: f6a8110) Message: undefined" viewer.js:6023:5 The exploit script has been attached! Steps to reproduce (at the time of writing): 1. Visited: http://www.themoscowtimes.com/news/article/duma-considers-anti-terrorism-bill-for-online-payments/492780.html 2. 'Ad' was loaded in the background: http://185.86.77.48/ads.php 3. Which loaded: http://185.86.77.48/counter.php (File has been attached to report) 4. Counter.php contained script which created an iframe and started accessing system files (/.ssh/id_rsa, known_hosts etc.), sending the contents in a POST payload to: http://185.86.77.48/banner.php (with some GET parameters). It looks like the script is also configured to exploit the same bug on Windows so different files may be accessed with that OS. The files that are targeted can be found in plain-text in the script. System details: Browser: Firefox 39.0, Mozilla Firefox for Ubuntu canonical - 1.0 OS: Ubuntu 15.04 Actual results: NA Expected results: NA

It's probably a combination of https://www.mozilla.org/en-US/security/advisories/mfsa2015-69/ (Privilege escalation through internal workers, July 2, 2015) and a (new) Same Origin Policy bypass.

Investigating.

I'm unclear as to whether ESR38 is affected. Comment 1 makes me think no but the comment is not definitive enough for me to mark ESR38 as unaffected.

(In reply to Lawrence Mandel [:lmandel] (use needinfo) from comment #3) > I'm unclear as to whether ESR38 is affected. Comment 1 makes me think no but > the comment is not definitive enough for me to mark ESR38 as unaffected. comment 1 isn't accurate. ESR38 is almost certainly affected.

Tracked for ESR38.

In case if we decide to disable PlayPreview used in PDF Viewer, I attached uplift patches for bug 1179262 for Firefox 40 and 38esr there. Firefox 42 already contains the fix.

Bug 1178058 is the relevant one here.

The exploit code here appears to be targeted at developers - it steals credentials for ftp, s3, svn, sql, etc, and sends them to 185.86.77.48. 185.86.77.48 is in the Ukraine, and comment 0 indicates that it's targeting people in Moscow/Russia. That's certainly very interesting, but let's stay focused on getting this patched.

Bobby: are the changes to nsExpandedPrincipal in bug 1178058 sufficient to fix this bug in Firefox 40, or does its effectiveness on Nightly subtly depend on other changes that might have landed in the past couple of months? Ditto for ESR-38 which is missing another three months worth of development work?

(In reply to Daniel Veditz [:dveditz] from comment #9) > Bobby: are the changes to nsExpandedPrincipal in bug 1178058 sufficient to > fix this bug in Firefox 40, or does its effectiveness on Nightly subtly > depend on other changes that might have landed in the past couple of months? > Ditto for ESR-38 which is missing another three months worth of development > work? I think they should be independently backportable, but it's difficult to be certain. I recommend uplifting both bug 1178058 and bug 1179262. I am working on getting a deeper understanding of this testcase in order to gain additional certainty that everything is fixed, but I think that can happen in parallel with the above.

I am glad to see this was picked up so fast. @bholley Indeed very interesting. The website is actually in English (International) but it's a Russian news agency so for all I know they didn't target a specific country or region. I tested with a Dutch and German VPN and both times the iframe loading the malicious script was included.

Lawrence, I recommend uplifting bug 1179262 as well, but we should discuss it here rather than in the other bug (which is public). Does the patch look ok to take?

Yury: is there anything in the PDF reader we could quickly disable with a hotfix add-on that would short-circuit this exploit until we can ship real (and tested!) patches? Obviously we could disable the entire PDF reader easily, but that dumps millions of people back into Adobe Reader and I'm not sure that's any better given how many users have outdated versions and how many active exploits there are for _that_! Any way to disable the 'application/x-moz-playpreview-pdfjs' handler or override its registration with a do-nothing component?

(In reply to Daniel Veditz [:dveditz] from comment #13) > Yury: is there anything in the PDF reader we could quickly disable with a > hotfix add-on that would short-circuit this exploit until we can ship real > (and tested!) patches? Obviously we could disable the entire PDF reader > easily, but that dumps millions of people back into Adobe Reader and I'm not > sure that's any better given how many users have outdated versions and how > many active exploits there are for _that_! > > Any way to disable the 'application/x-moz-playpreview-pdfjs' handler or > override its registration with a do-nothing component? Yes, the bug 1179262 does just that and it's currently landed in Firefox 42 (so this bug shall not affect the Nightly)

Bobby, given that the patch for bug 1179262 has been in Nightly for a month now it seems safe to uplift. However, while reviewing that patch I noticed the classID line (copied below). Is this a UUID change? I was told that UUID changes are not ok in Aurora, Beta channels. Not that it would stop us in this case, but just wanted your comment on that aspect. + classID2: Components.ID('{d0c5195d-e798-49d4-b1d3-9324328b2292}'),

I've verified that on aurora the patches from bug 1178058 and bug 1179262 both independently fix the testcase from bug 1178058 (which formed the basis for the exploit code). I still think it would be a good idea to take both.

(In reply to Ritu Kothari (:ritu) from comment #15) > Is this a UUID change? I was told that UUID > changes are not ok in Aurora, Beta channels. Not that it would stop us in > this case, but just wanted your comment on that aspect. > > + classID2: Components.ID('{d0c5195d-e798-49d4-b1d3-9324328b2292}'), Yury might be a better person to ask about that.

(In reply to Ritu Kothari (:ritu) from comment #15) > Bobby, given that the patch for bug 1179262 has been in Nightly for a month > now it seems safe to uplift. However, while reviewing that patch I noticed > the classID line (copied below). Is this a UUID change? I was told that UUID > changes are not ok in Aurora, Beta channels. Not that it would stop us in > this case, but just wanted your comment on that aspect. > > + classID2: Components.ID('{d0c5195d-e798-49d4-b1d3-9324328b2292}'), It does not constitute the kind of UUID change we're worried about for uplifts.

(In reply to Yury Delendik (:yury) from comment #14) > > Any way to disable the 'application/x-moz-playpreview-pdfjs' handler or > > override its registration with a do-nothing component? > > Yes, the bug 1179262 does just that and it's currently landed in Firefox 42 > (so this bug shall not affect the Nightly) Sorry if I wasn't clear enough: I meant "Any way to do that from a hotfix add-on?" The patch in bug 1179262 contains changes to Firefox binaries. I'm not sure a hotfix add-on could simulate those or monkey-patch around it.

(In reply to Daniel Veditz [:dveditz] from comment #19) > Sorry if I wasn't clear enough: I meant "Any way to do that from a hotfix > add-on?" The patch in bug 1179262 contains changes to Firefox binaries. I'm > not sure a hotfix add-on could simulate those or monkey-patch around it. This fix requires platform support, I think.

(In reply to Bobby Holley (:bholley) from comment #12) > Lawrence, I recommend uplifting bug 1179262 as well, but we should discuss > it here rather than in the other bug (which is public). Does the patch look > ok to take? Yes. It has more code change that I'd like to see at this point in a release but it has been on m-c for a month and the usual rules don't apply to 0 day bugs. I would definitely prefer that we verify that the fix is good before we take the changes. ESR31 is EOL on Tuesday but, if we ship a chemspill we need to include ESR31 as it is still an actively supported branch. Is ESR31 affected?

(In reply to Lawrence Mandel [:lmandel] (use needinfo) from comment #21) > I would definitely prefer that we verify that the fix is good before > we take the changes. nm. Just read comment 16.

One more in my string of comments, is fennec affected?

(In reply to Lawrence Mandel [:lmandel] (use needinfo) from comment #23) > One more in my string of comments, is fennec affected? According to Yury we don't use pdf.js on Fennec, so no.

(In reply to Daniel Veditz [:dveditz] from comment #19) > (In reply to Yury Delendik (:yury) from comment #14) > > > Any way to disable the 'application/x-moz-playpreview-pdfjs' handler or > > > override its registration with a do-nothing component? > > > > Yes, the bug 1179262 does just that and it's currently landed in Firefox 42 > > (so this bug shall not affect the Nightly) > > Sorry if I wasn't clear enough: I meant "Any way to do that from a hotfix > add-on?" The patch in bug 1179262 contains changes to Firefox binaries. I'm > not sure a hotfix add-on could simulate those or monkey-patch around it. No, there is not. The patch in the Firefox binaries allows stream converter for PDF content work even when EMBED tag is used and that cannot be done with just add-on. However simple disabling of Play Preview for EMBED tag, potentially can be done with add-on code (e.g. by overriding PdfRedirector.jsm to not do anything), but this will be a loss of functionality for content that uses embedded PDFs.

OK, it sounds like we be landing both patches mentioned in comment 16. Then we should land them on a relbranch and on m-r, m-b, and m-a. Once they land I can start a build for 39.0.1 and ESR 38. Can someone help out in figuring out whether ESR 31 is affected?

(In reply to Yury Delendik (:yury) from comment #25) > No, there is not. The patch in the Firefox binaries allows stream converter > for PDF content work even when EMBED tag is used and that cannot be done > with just add-on. However simple disabling of Play Preview for EMBED tag, > potentially can be done with add-on code (e.g. by overriding > PdfRedirector.jsm to not do anything), but this will be a loss of > functionality for content that uses embedded PDFs. That could be promising, right? A hotfix that disables embedding for a few days until we can release Firefox 40 might be better than a full chemspill on 39.0.x, 38.1.x and possibly 31.8.x. Then again we know how to do chemspills but hotfix add-ons are bespoke and might require more testing to make sure we got it right.

Well, we know that the patch(es) worked in Nightly, so that makes me think we have a good chance these fixes will work in other versions. And, we have that fix already. I kind of wish we had called it the other way, earlier, but we are about to land the patches from both bugs and start the builds for 39.0.3 and 38.1.1esr so, onwards with the chemspilling.

Okay, the patches from both bugs have been uplifted to aurora/beta/release/esr38 (and the two relbranches). We haven't uplifted to esr31 yet. Don't know if we need to.

For what it's worth I cannot reproduce the 1178058 testcase on ESR-31. In the dev-tools console I get Error: stream must have data" pdf.worker.js:215 assert@resource://pdf.js/build/pdf.worker.js:232:5 init@resource://pdf.js/build/pdf.worker.js:4615:5 PDFDocument@resource://pdf.js/build/pdf.worker.js:4606:7 LocalPdfManager@resource://pdf.js/build/pdf.worker.js:4201:5 getPdfManager@resource://pdf.js/build/pdf.worker.js:36831:11 wphSetupDoc@resource://pdf.js/build/pdf.worker.js:36997:7 messageHandlerComObjOnMessage@resource://pdf.js/build/pdf.worker.js:1115:9 I don't know if the problem can be worked around or if that version of Firefox and/or the PDF reader is missing a crucial feature, but at least the 0-day won't work as written.

Note - to verify this bug without sending the contents of your hard drive to the Ukraine, use the test in bug 1178058. Note that that testcase is designed to work on Windows and Linux - you'll need to modify it to make it work on Mac.

Can we call this fixed now?

Yes, this is fixed by landing the patches in the other two bugs, and now released.

Found a variant pasted on ubuntu pastebin. This one *does* go after Mac users, slightly different set of interesting files (but same developer-type focus). Not sure about all the '!' at the beginning of the file, they were in the pastebin like that. I have no idea where it was found. Uploading file in case pastebin expires http://paste.ubuntu.com/12030863/ Found via Twitter https://twitter.com/_argp/status/630409999324479488

Found another one on Debian's pastebin. more similar to the Ubuntu one than the one originally reported here. https://paste.debian.net/?show=290146;lines=0 Also notice the n.version="1.0.7" in the Ubuntu one. That's not in either of the others, but suggestive this may have been out for a some time.

The Debian pastebin was uploaded the day before the Ubuntu version so maybe it's evolving. Also, found via @hdmoore's retweet of https://twitter.com/PhysicalDrive0/status/630469684341645312

What's interesting is that the list of targeted files is longer but this list no longer includes the public key ('id_rsa.pub'). The only reason I noticed the file theft was because when it tried to open my public key file it triggered a file dialog because Firefox determined the file was executable because of the 'application/vnd.ms-publisher' mimetype associated with the .pub file extension. All other files in the list either have no file extension or a file extension that returns a mimetype the browser can handle (e.g. file extension .xml). The only exception in the list is *.sh. These files seem to trigger file dialogs too but of course not everyone has shellscript files so the file theft could still go unnoticed. What's also interesting is that in this case the targets actually seem to be Russians. It also seems to have been modified by someone other than the original author who's English is clearly not as good, see for example the variable named 'interessed_text_files'.

(In reply to Bobby Holley (:bholley) from comment #31) > Note - to verify this bug without sending the contents of your hard drive to > the Ukraine, use the test in bug 1178058. Note that that testcase is > designed to work on Windows and Linux - you'll need to modify it to make it > work on Mac. Landry Breuil managed to do some verification here: https://bugzilla.mozilla.org/show_bug.cgi?id=1178058#c66.

What was the exact breach or pot hole for this bug? I am new to bugzilla and trying to learn about this bug.

(In reply to Akshay Jain from comment #39) > What was the exact breach or pot hole for this bug? > I am new to bugzilla and trying to learn about this bug. This bug was related to a poorly-thought-out technology called PlayPreview which has since been removed from gecko (bug 1179262). Now that it's gone I've done my best to forget all about it, and so a precise explanation of the failure mode would take me a long time to write. It would also probably take a lot of background-research for a non-gecko-security-hacker to understand, and that time wouldn't be all that well spent because most of the systems involved have been deleated. If you'd like to understand a devious and complicated gecko bug start to finish, I might recommend the one described in bug 863933 comment 5. All of the stuff referenced there is pretty well-documented, but still would probably take months for an outsider to understand. If you can grok that bug, my hat goes off to you. ;-)

s/background-research/background research/ s/deleated/deleted/. Sorry for the typos - in a bit of a hurry going through my backlog. :\