Closed Bug 901365 Opened 12 years ago Closed 12 years ago

Firefox 0-day found on Tor .onion service (reported on Reddit)

Categories

(Core :: Security, defect)

x86_64
Windows 7
defect
Not set
normal

Tracking

()

RESOLVED FIXED
Tracking Status
firefox-esr17 22+ fixed
firefox-esr24 --- fixed
b2g18 22+ fixed
b2g18-v1.0.1 --- wontfix
b2g-v1.1hd --- fixed
b2g-v1.2 --- fixed

People

(Reporter: dveditz, Unassigned)

References

()

Details

(Keywords: sec-critical, Whiteboard: fixed by June 25, 2013 releases in bug 857883)

Crash Data

Attachments

(5 files)

Reddit is reporting a Firefox 0-day that has been injected on some .onion sites (Tor hidden services). http://www.reddit.com/r/onions/comments/1jmrta/founder_of_the_freedom_hosting_arrested_held/ The most complete link I've seen appears to be http://pastebin.mozilla.org/2777139 (and copied to http://pastebin.mozilla.org/2781408 in case the first link is ephemeral) I've also seen http://pastebin.com/pmGEj9bV http://pastebin.com/K61QZpzb http://pastebin.mozilla.org/2776374 and I'm not sure where they're all from or how they're related (look duplicative). No point in hiding the bug at this point, this is all over the twitters and will just collect dupes.
This appears to be the exploit, linked by reddit: http://pastebin.mozilla.org/2776374
(In reply to Bobby Holley (:bholley) from comment #1) > This appears to be the exploit, linked by reddit: > > http://pastebin.mozilla.org/2776374 oh, ignore me. dveditz already linked to it in comment 0.
Can someone with a windows build run this thing in an ASAN debug build and see where we first fall over?
Can you make this crash on non-windows?
Attached file pastebin-pmGEj9bV.txt
This has now been posted to Hacker News. Here's the URL to help catch dupes https://news.ycombinator.com/item?id=6154246
Summary: Onion service Firefox 0-day (reported on Reddit) → Firefox 0-day found on Tor .onion service (reported on Reddit)
Whiteboard: Possibly ESR-17 only
Until content_2.html is loaded it looks like mere heap ordering. I can't get nightly to crash with it. Will look at content_2.html next.
content_2.html seems to trigger over-recursion on linux.
(In reply to Bobby Holley (:bholley) from comment #11) > content_2.html seems to trigger over-recursion on linux. Oh, nevermind. That only happens when you don't load the iframes in the proper hierarchy, because the parent structure isn't what the code expects.
I have to go, but some notes on making the testcase actually do something: If the version check fails, the main frame is redirected to content_1.html, which appears to be the bailout page. Depending on your platform, it may be necessary to early-return |17| from |function al()| in the main exploit. The exploit appears to try to wait for onload before executing, but fails, because the event listener at the bottom is |u()| rather than |u|, so it effectively evaluates the whole exploit when it adds the event handler. This means that the iframe needs to have the bizarre pre-positioning it has in the exploit. Don't try to re-order it.
smaug points out both the crash stack and fix range seem consistent with bug 857883. (At least for the crash I'm seeing; possible others see something else!)
And to be clear: I'm testing on Linux. Somebody should definitely check on Windows.
As a side note, these crashes cause the exploitability analyzer in crash-stats to error out. Filed bug 901372 for that.
(In reply to Daniel Veditz [:dveditz] from comment #0) > Reddit is reporting a Firefox 0-day that has been injected on some .onion > sites (Tor hidden services). > > http://www.reddit.com/r/onions/comments/1jmrta/ > founder_of_the_freedom_hosting_arrested_held/ > ... (In reply to David Baron [:dbaron] (don't cc:, use needinfo? instead) from comment #15) > Using the testcase in: > https://hg.mozilla.org/users/dbaron_mozilla.com/bug901365-testcase/ > I crash in Firefox 17.0, 17.0.4esr, and 17.0.6esr but NOT 17.0.7esr at: > bp-3534f587-63b8-43cf-9891-5dad22130804 > bp-f4517677-20f6-4a09-aaed-ab5082130804 > bp-82eaa8cd-83e3-49a0-ad8a-e7cd12130804 Is this an issue with Thunderbird 17 esr?
(from comment #16) > smaug points out both the crash stack and fix range seem consistent with > bug 857883. That would be http://www.mozilla.org/security/announce/2013/mfsa2013-53.html if so.
Ok, here is a description of how it breaks in: - d fills up the memory, with interleaved allocations of Arrays and ArrayBuffers. - c instantiate a new iframe to call into the parent one. I still don't know if this iframe is needed or just the cross-compartment call. - The iframe calls into w(), which verify if there is any memory corruption in 2 ways: - either using k(), in case the ArrayBuffer overflow on the next ArrayBuffer. - or using p(), in case the ArrayBuffer overflow on an Array. in both cases, they are checking the offset of the length property, such as: var2[j].byteLength!=var5 var3[j][i*0x4000-0x02]==0x01000000
Open start.html to begin. Doesn't always crash, sometimes I had to reload or shift-reload it a few times.
Crash Signature: [@ nsPresContext::SetImageAnimationModeInternal(unsigned short) ] [@ nsPresContext::SetImageAnimationModeInternal ]
So far I've reproduced the crash using attachment 785556 [details] in https://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2013/05/2013-05-05-03-45-01-mozilla-esr17/ But not with https://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2013/05/2013-05-17-03-45-04-mozilla-esr17/ I couldn't find any builds in between, I think we only build ESR on demand. The only fixes in that range are three bugs fixed by Olli, bug 857883 (the suspected fix), bug 862309 (related to contenteditable), and bug 866915 (related to XHR) http://hg.mozilla.org/releases/mozilla-esr17/pushloghtml?startdate=2013-05-05&enddate=2013-05-17
I've also confirmed that mozilla-central 2013-05-15 nightlies crash and 2013-05-16 nightlies don't. That also aligns with bug 857883
I've been told comment 23 and 24 can be cryptic for those who aren't up on our archive nomenclature. All of these were "nightly" developer/testing builds. The first build in comment 23 is a more-or-less stock ESR 17.0.6 built May 5, 2013 and the second contained only Olli's patches and was built on May 17, 2013. The "pushloghtml" link shows the ESR code changes in that date range. In comment 24 I was talking about May nightlies of "mozilla-central", which was Firefox 24 at the time. The patch for bug 857883 was also applied to the Fx23 "Aurora" branch and the Fx22 "Beta" branch. Firefox 22 and Firefox ESR 17.0.7 were released on June 25, 2013 and contained the patch for bug 857883 and are not affected by the exploit samples that we have received related to this issue.
Should we close this bug?
Firefox OS 1.0.1 seems to be affected as well — dbaron's copy of the exploit crashes the content process (i.e., the browser tab). Assuming it's bug 857883, 1.1.0 and up have the fix and 1.0.0 is also affected, but I haven't tested other versions yet.
We should probably prepare a 1.01 specific patch for bug 857883 and land it on the 1.01 branch.
I'd guess the patch for bug 857883 should work as-is. (It applied cleanly to esr17 too, which is older than b2g18)
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Whiteboard: Possibly ESR-17 only → fixed by June 25, 2013 releases in bug 857883
Hey, guys, would you please give a detailed description of attachment "self-contained exploit w/neutered (hopefully) shellcode (6.93 KB, application/java-archive)" by "2013-08-04 16:06 PDT, Daniel Veditz [:dveditz]"? I just could not understand much about the process of triggering and exploiting. Please contact 1989600235@qq.com if you are willing to offer a help.Thank you so much!
Comment 21 is private: false
Comment 27 is private: false
Comment 28 is private: false
Comment 29 is private: false
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: