Bug 555109 (CVE-2010-1121)

Move wrappers to new scope even if their parent hasn't been moved yet (ZDI-CAN-761)

RESOLVED FIXED in mozilla1.9.3a4

Status

()

Core
Security
--
critical
RESOLVED FIXED
8 years ago
5 years ago

People

(Reporter: reed, Assigned: mrbkap)

Tracking

({regression, verified1.9.1, verified1.9.2})

unspecified
mozilla1.9.3a4
regression, verified1.9.1, verified1.9.2
Points:
---
Bug Flags:
wanted1.9.0.x +
in-testsuite ?

Firefox Tracking Flags

(blocking2.0 betaN+, blocking1.9.2 .3+, status1.9.2 .3-fixed, blocking1.9.1 .10+, status1.9.1 .10-fixed)

Details

(Whiteboard: [sg:critical][keep hidden until 3.5.10 release] Pwn2Own 2010 bug)

Attachments

(8 attachments, 3 obsolete attachments)

(Reporter)

Description

8 years ago
Placeholder for Pwn2Own bug found in Firefox at CanSecWest 2010 (CVE-2010-1121).
ZDI-CAN-761: Pwn2Own: Mozilla Firefox Code Execution Vulnerability

-- ABSTRACT ------------------------------------------------------------
TippingPoint has identified a vulnerability affecting the following 
products:

Mozilla Firefox 3.6.x

-- VULNERABILITY DETAILS -----------------------------------------------
This vulnerability was received through the 2010 Pwn2Own competition at
CanSecWest on March 24th. It is a remotely executable code execution
vulnerability affecting the latest available versions of Mozilla
Firefox.

The attached PoC was directly provided to us from the contestant at the
competition. Launch index.html to reproduce. It appears the crux of the
issue lies here:

function start() { 
o61=document.getElementById('container').contentDocument.createElement('button');
o61.toString();

document.getElementById('container').contentWindow.location.reload(); 
window.setTimeout('start2()',100); 
} 

function start2() { 
o101=document.getElementById('container').contentDocument.createElement('b');
o61.ownerDocument.open();
o101.appendChild(o61);
o61 = null;
gc();

location.href = 'hs.html';}

This is a cursory analysis. We expect to have a follow-up next week when
we have had time to dissect the supplied details further. We appreciate
updates and any additional details you may have on the matter as well.

Version(s) tested: Latest version of Firefox as of 3/24/2010
Platform(s) tested: Latest version of Windows 7 as of 3/24/2010

-- CREDIT --------------------------------------------------------------
This vulnerability was discovered by:

* Nils of MWR InfoSecurity
Summary: ZDI CanSecWest 2010 bug → ZDI CanSecWest 2010 bug (ZDI-CAN-761)
Created attachment 435259 [details]
PoC from ZDI
blocking1.9.1: --- → ?
blocking1.9.2: --- → .3+
blocking2.0: --- → ?
status1.9.1: --- → ?
status1.9.2: --- → wanted

Comment 3

8 years ago
> Version(s) tested: Latest version of Firefox as of 3/24/2010
> Platform(s) tested: Latest version of Windows 7 as of 3/24/2010

This article indicates the vulnerability might only be present on 64-bit system with windows 7.  http://tech.spreadit.org/pwn2own-2010/

Other press has indicate that the results of the test case should launch calc.exe.  We need to figure out if that is what we are watching for.

Checking the test case on a 32bit win XP vm with Firefox 3.6.2 it doesn't appear to show any problems.  The test case has been running for several hours.  It soaks up 99% cpu use and its up to 300MB of memory use, but no other indications of problems.
The payload does look like the standard calc-launcher (I haven't compared to metasploit to verify). I'm not surprised that part didn't "work" if you're not on a Win7 machine, but I'm surprised it didn't crash (I don't crash on WinXp 32-bit either). Part of the exploit looks like he's trying to mimic a particular object's memory layout, maybe on the not-quite-right target it just plays nice.

Mac crashes right away though
bp-ed75037c-a4e1-4b5e-a6db-a6dc22100327
bp-c5c500d3-c706-44ee-9262-2df672100327

I haven't crashed on Shiretoko on Mac, nor Minefield.
Keywords: regressionwindow-wanted
Whiteboard: [sg:critical] ZDI CanSecWest 2010 bug → [sg:critical] ZDI CanSecWest 2010 bug [fix-window-wanted?]
Now that I've submitted the above I can crash Namoroka on 32-bit WinXP.

bp-c39ba86f-d9cb-4aee-8da9-a92a82100327
bp-c2d04bf0-f376-4574-bd66-4454c2100327

Comment 6

8 years ago
On vista I've now seen these two crashes
bp-c5e33206-3377-4343-bf0f-d73062100327 bp-1b16ab19-3b1a-4111-ad70-c0ebd2100327
and I've also now seen two cases where calc was launched.

Comment 7

8 years ago
no crashes for me on vista with 3.5.8 or a 3.0.x build.  they seem to pretty immune and fast and responsive when running the test case.

I've gotten a couple of crashes on 3.6b1 but no calc.exe's
bp-e0e960fe-74b5-4bee-9beb-27f632100327
bp-4d795788-2c2b-4676-8ff6-2cfda2100327
these stacks look quite a bit different than the others and we crash pretty quickly on 3.6 beta1

Comment 8

8 years ago
Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2a2pre) Gecko/20090901 Namoroka/3.6a2pre  crashes but I can't get past the windows crash dialog to submit a report.

Comment 9

8 years ago
a rough regression range might be sometime in July

 Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2a1pre) Gecko/20090630 Minefield/3.6a1pre -- no crash - response like 3.5.x

3.6a1pre  Build ID 20090731 044744  crashes like
607cbb0b-9b9b-441e-8226-afffd2100327 and 15c87ec7-d721-46dc-b8a8-339252100327

Comment 10

8 years ago
narrowing futher it looks like july30-july31 could be the range.  

mozilla-central/3.6a1pre builds on and before july30 behave a more like 3.5.x, and the july 31 build on windows vista crashes consistently for me within a few seconds of loading the PoC.
a rough fix range on mozilla-central seems to be between 2009-11-09-04 and 1109-11-11-04. I'd check that last day in between but I'm late for dinner.

Comment 12

8 years ago
(In reply to comment #11)
> a rough fix range on mozilla-central seems to be between 2009-11-09-04 and
> 1109-11-11-04. I'd check that last day in between but I'm late for dinner.

NT 6.0; en-US; rv:1.9.3a1pre) Gecko/20091110 Minefield/3.7a1pre  
crashes a few seconds after loading the test case for me.

Comment 13

8 years ago
and no crash on Windows NT 6.0; en-US; rv:1.9.3a1pre) Gecko/20091111 Minefield/3.7a1pre

so I think the summary is 

appears to be broken on mozilla-central after july31 and before nov10 -- then fixed then possibly fixed after that.  

3.6betas and 3.6.x don't appear to have picked up the fix after it branched.

3.5.x appears to never have been affected.
Regression range (dates from comment 10):
http://hg.mozilla.org/mozilla-central/pushloghtml?startdate=2009-07-30&enddate=2009-07-31%2005:00

The fix range (changesets pulled from about:buildconfig):
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=f4ef40336cc6&tochange=2eb351cc47d3

Nothing in the regression range stands out. I think Jonas's fix for bug 507023 was too early and would have been in the previous day's build. Maybe one of bz's checkins, like bug 281387?

None of the check-ins in the fix range seem likely to match up with damage from the bustage range.
Whiteboard: [sg:critical] ZDI CanSecWest 2010 bug [fix-window-wanted?] → [sg:critical] ZDI CanSecWest 2010 bug
Keywords: regressionwindow-wanted → regression
http://hg.mozilla.org/mozilla-central/rev/f7ea35747ee3 doesn't crash.
http://hg.mozilla.org/mozilla-central/rev/3222b99f441c - " -
http://hg.mozilla.org/mozilla-central/rev/c1ab8650e0ce - " -
http://hg.mozilla.org/mozilla-central/rev/8cff4bd2121a - " -
http://hg.mozilla.org/mozilla-central/rev/0a0b0c3f614b - " -
http://hg.mozilla.org/mozilla-central/rev/0a8bed5ebe1a - " -

http://hg.mozilla.org/mozilla-central/rev/65e30d612773 crashes <---
http://hg.mozilla.org/mozilla-central/rev/cd25ab8c2f30 crashes
http://hg.mozilla.org/mozilla-central/rev/8cd49a8cbb88 crashes

I was testing my 1.9.2 tree, I'll verify with a different tree (m-c),
although those should the same at the time of that changeset
Verified:
http://hg.mozilla.org/mozilla-central/rev/0a8bed5ebe1a doesn't crash
http://hg.mozilla.org/mozilla-central/rev/65e30d612773 crashes

I believe something in Bug 492713 doesn't handle document.open properly.
Maybe something in prototype handling of the old inner window, but I'm
just guessing. Need to find out the unregress-patch.
http://hg.mozilla.org/mozilla-central/rev/85e238958d37 crashes
http://hg.mozilla.org/mozilla-central/rev/2f5d97dd7e56 doesn't crash <--
http://hg.mozilla.org/mozilla-central/rev/2f5d97dd7e56 does apply to 1.9.2 
and it does fix the crash, but I wonder if that merely accidentally prevents
the crash in this case.

peter, jst, blake, you probably know this better.

Btw, I'm testing on 64bit linux.
http://hg.mozilla.org/mozilla-central/rev/2f5d97dd7e56 fixed Bug 526201
(commit message misses the bug#)
That's weird, it just removed a call to MorphSlimWrapper because it wasn't needed in some cases, it wasn't expected to fix any crashes. We should figure out what's going wrong without it.
So what's next steps to knowing the appropriate fix for this issue?
Created attachment 435574 [details]
a stack

wrapper->GetFlatJSObject() seems to return either null or some
garbage.
This all looks very much like a xpconnect/wrapper handling bug.
But I'm not at all familiar with this code, so hopefully
mrbkap, peterv or jst could look at this.
Not affecting 1.9.1.x as per comment 15
blocking1.9.1: ? → -
status1.9.1: ? → unaffected
(Reporter)

Updated

8 years ago
Attachment #435574 - Attachment is patch: false

Updated

8 years ago
blocking1.9.1: - → ?
status1.9.1: unaffected → ?
Martijn: did you intend to change the blocking and status flags for the 1.9.1 branch back to ? or was that a bugzilla accident?
Sorry, bugzilla accident.
So this is a bug in nsXPConnect::ReparentScopeAwareWrappers() where depending on the order in which the wrappers in the given scope end up being reparented we either reparent them or we don't. The key in the testcase is the call to document.open(), which triggers the call to nsXPConnect::ReparentScopeAwareWrappers(), and if we in that code end up reparenting the document before we reparent nodes that belong to that document, we're fine, but if the order is reversed, we end up not reparenting all wrappers and later on can leave dangling wrapper pointers in XPConnect's hashes, which leads to the crash/exploit.

We have a fix that fixes this particular crash, but not all variations of it. mrbkap is working on a complete fix and expects to have that done tomorrow.

And this code goes way back, at least to 1.9.0, so 1.9.1 is for sure affected, as is trunk, the testcase just needs to be different to trigger it (but we don't know quite how).
blocking1.9.1: ? → ---
And kudos for finding all this out goes to mrbkap and peterv, I'm just the messenger.
(Assignee)

Comment 29

8 years ago
Created attachment 435801 [details] [diff] [review]
Debugging patch

This patch was immensely useful to me when debugging this. I suspect it would be less useful to other people, but I'm attaching it here for reference.
Assignee: nobody → mrbkap
Status: NEW → ASSIGNED
(Assignee)

Comment 30

8 years ago
Created attachment 435802 [details] [diff] [review]
wip

This patch works, but I'm leaking a ton with it. I'll debug more tomorrow.

I also have concerns about objects that return a newParent from their PreCreate hooks that is tied to the old global. I'm considering recursively calling the PreCreate hook up the chain (and possibly memoizing results) to protect against such objects.
We're leaking documents, in the CC I see a small cycle between the document for sploit/main.html , a parser and a content sink, but there's an unknown edge to the document too. I'm still trying to figure out what that edge is.
Created attachment 435936 [details] [diff] [review]
Leak fix

This fixes the leaks for me. Need to hook up HTMLContentSink to CC. We probably need to add more of if members still.
Created attachment 435993 [details] [diff] [review]
Leak fix

This is a more complete leak fix. I think this should be safe to do (even the unlinking). There's still the context stack, but I don't know how likely it is that we'll have cycles through that.
Can you guys confirm that this fixes all the leaks from attachment 435802 [details] [diff] [review]?
Attachment #435936 - Attachment is obsolete: true
Attachment #435993 - Flags: review?(jst)
Yes, with the last two patches applied I can leave the testcase run w/o any obvious leaks!
Oh, and I pushed a combination of the above two patches to try.
Are these trunk and 1.9.2 only?
(Assignee)

Comment 37

8 years ago
Al, I believe that peter's patch applies to trunk (and needs massaging to work on 1.9.2)... I wrote my patch against 1.9.2, but I don't think any of the code it touches has changed in the past few years, so should apply cleanly to mozilla-central.
We should get the work landed on trunk as soon as we know it's likely to be the solution.
blocking1.9.1: --- → ?
When we check in this thing, I want us to have a good sense of what it might break and what QA can do to verify that we aren't going to ship something with unintended consequences. Right now, we have a single testcase and that doesn't seem like enough data to ship this.

Can we get automated tests for this to be checked in after we ship? Can dev give an idea of the potential consequences of this fix and where we might break Firefox or extensions, etc?
(Assignee)

Comment 40

8 years ago
Created attachment 436052 [details] [diff] [review]
Crash fix

jst and I decided to stick with this approach. It's correct for the DOM, but potentially not if a weird extension defines certain types of C++ scriptable objects with bizarro properties.

I have a sketch of a patch (I haven't even compiled it yet) that should help deal with even weird objects, but this is far and away less risky and less code.
Attachment #435802 - Attachment is obsolete: true
Attachment #436052 - Flags: review?(jst)
(Assignee)

Comment 41

8 years ago
Created attachment 436053 [details] [diff] [review]
Crash fix

Forgot to qrefresh.
Attachment #436052 - Attachment is obsolete: true
Attachment #436053 - Flags: review?(jst)
Attachment #436052 - Flags: review?(jst)
tracking-fennec: --- → ?
Flags: wanted1.9.0.x+
Comment on attachment 435993 [details] [diff] [review]
Leak fix

Looks good, and tested good!
Attachment #435993 - Flags: review?(jst) → review+

Updated

8 years ago
Attachment #436053 - Flags: review?(jst) → review+
(Assignee)

Comment 43

8 years ago
Created attachment 436089 [details] [diff] [review]
Alterna-patch sketch

This patch also fixes this bug, and is more resilient in the face of weird chains of objects that don't actually want to move. We decided that this isn't necessarily needed, so I'm just attaching it here fore reference.
(Reporter)

Updated

8 years ago
status2.0: --- → ?
I've split off the leak fix into bug 556241. I'll try to make a testcase just for the leak.
Attachment #436053 - Flags: superreview+
Comment on attachment 436053 [details] [diff] [review]
Crash fix

>diff --git a/js/src/xpconnect/idl/nsIXPConnect.idl b/js/src/xpconnect/idl/nsIXPConnect.idl

>+        JSObject *newParent = aOldScope;
>+
>         // If the wrapper doesn't want precreate, then we don't need to
>         // worry about reparenting it.
>         if(!sciWrapper.GetFlags().WantPreCreate())
>             continue;
> 
>-        JSObject *newParent = aOldScope;
>         rv = sciWrapper.GetCallback()->PreCreate(identity, ccx, aOldScope,
>                                                  &newParent);

That change looks unnecessary. I'll push a patch without it.
(Reporter)

Updated

8 years ago
Summary: ZDI CanSecWest 2010 bug (ZDI-CAN-761) → Move wrappers to new scope even if their parent hasn't been moved yet (ZDI-CAN-761)
http://hg.mozilla.org/mozilla-central/rev/b5f44530499b

Nightlies were respun and should have this fix.
Status: ASSIGNED → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9.3a4
(In reply to comment #44)
> I've split off the leak fix into bug 556241. I'll try to make a testcase just
> for the leak.

So that bug needs to block everwhere this one does? Or we add it to the "Depends on" list? Seems like a recipe for forgetting it.

I guess for trunk that's fine, but for branches we'd like a combined patch anyway just to make sure everything goes in. (bonus points for obfuscating the actual fix a little.)
blocking1.9.1: ? → .10+
status1.9.1: ? → wanted
Whiteboard: [sg:critical] ZDI CanSecWest 2010 bug → [sg:critical] ZDI CanSecWest 2010 bug [needs bug 556241 fix too]
(Assignee)

Updated

8 years ago
Attachment #436053 - Flags: approval1.9.2.3?
Comment on attachment 436053 [details] [diff] [review]
Crash fix

Approved for 1.9.2.3 and 1.9.2.4, a=dveditz for release-drivers

Please wait for the 1.9.2 branch tinderboxen to go green after checking in (1.9.2.4) before checking into the relbranch (1.9.2.3).

Although this patch is slightly different than what was ultimately checked in, mrbkap says he will be qimporting the actual checkin to make sure the branches match.
Attachment #436053 - Flags: approval1.9.2.3? → approval1.9.2.3+
Depends on: 556241
(In reply to comment #48)
> Please wait for the 1.9.2 branch tinderboxen to go green after checking in
> (1.9.2.4) before checking into the relbranch (1.9.2.3).

Why? We should land on both branches at the same time, IMO, so that we can spin builds as soon as the trees turn green.

mrbkap - do you think you can land these tonight? The relbranch tag is FIREFOX_3_6_2_BUILD3 http://hg.mozilla.org/releases/mozilla-1.9.2/rev/cd857b3b0e33
blocking1.9.1: .10+ → ?
status1.9.1: wanted → ?
Correction to the branch for 1.9.2.3 - it's GECKO1922_20100315_RELBRANCH
(Assignee)

Comment 51

8 years ago
http://hg.mozilla.org/releases/mozilla-1.9.2/rev/dff821647de7 on the relbranch and
http://hg.mozilla.org/releases/mozilla-1.9.2/rev/98808d4a871f on the 1.9.2 default branch.
status1.9.2: wanted → .3-fixed
blocking1.9.2: .4+ → .3+
status1.9.2: .4-fixed → .3-fixed
Attachment #436053 - Flags: approval1.9.2.4+ → approval1.9.2.3+
Verified for 1.9.2.3 with:

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.3) Gecko/20100401 Firefox/3.6.3
Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.3) Gecko/20100401 Firefox/3.6.3
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.3) Gecko/20100401 Firefox/3.6.3

using the PoC, it no longer crashes.
Keywords: verified1.9.2
blocking1.9.1: ? → .10+
status1.9.1: ? → wanted
Whiteboard: [sg:critical] ZDI CanSecWest 2010 bug [needs bug 556241 fix too] → [sg:critical][keep hidden until 3.5.10 release] Pwn2Own 2010 bug
We do want a 1.9.1 branch patch for this (and bug 556241), and I'd be more comfortable having it ready just in case someone finds a way to exploit this in Firefox 3.5 and we need to firedrill.

Comment 54

7 years ago
Do we have an estimate of when this patch will be landed on 1.9.1? Could it possibly be done by tomorrow? Thanks!
(Assignee)

Comment 55

7 years ago
Created attachment 440035 [details] [diff] [review]
For 1.9.1
Attachment #440035 - Flags: review?(jst)

Updated

7 years ago
Attachment #440035 - Flags: review?(jst) → review+
(Assignee)

Updated

7 years ago
Attachment #440035 - Flags: approval1.9.1.10?

Comment 56

7 years ago
Comment on attachment 440035 [details] [diff] [review]
For 1.9.1

a=LegNeato for 1.9.1.10
Attachment #440035 - Flags: approval1.9.1.10? → approval1.9.1.10+
(Assignee)

Comment 57

7 years ago
http://hg.mozilla.org/releases/mozilla-1.9.1/rev/9caea2f858d2
status1.9.1: wanted → .10-fixed
I can't get this to crash with my 1.9.1 builds and others have noted above that the PoC, as written, doesn't trigger crashes on 1.9.1. There isn't anything that I can do to verify this for 1.9.1 specifically. The same fix in the same code fixed the issue in 1.9.2 though.

Comment 59

7 years ago
Created attachment 442644 [details] [diff] [review]
1.8 patch

1.8 backport to nsIXPConnect_MOZILLA_1_8_BRANCH
Attachment #442644 - Flags: review?(jst)

Updated

7 years ago
Attachment #442644 - Attachment is patch: true
Attachment #442644 - Attachment mime type: application/octet-stream → text/plain

Comment 60

7 years ago
Created attachment 443300 [details]
crash testcase

Al, does this testcase help?  Using this testcase, I can reproduce crashes on
fx-3.5.9, fx-3.6.2 and fx-3.7a4pre-2010-03-30-03.
Thanks for the testcase. That crashes 1.9.1.9 and passed on 1.9.1.10 on XP.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.10) Gecko/20100504 Firefox/3.5.10 (.NET CLR 3.5.30729)

Marking as verified for 1.9.1.
Keywords: verified1.9.1

Updated

7 years ago
Attachment #442644 - Flags: review?(jst) → review+
Comment on attachment 442644 [details] [diff] [review]
1.8 patch

Looks good, but please clean up the indentation here, remove *all* tabs.
Group: core-security
Flags: in-testsuite?

Updated

7 years ago
blocking2.0: ? → betaN+

Updated

7 years ago
tracking-fennec: ? → ---
status2.0: ? → ---
You need to log in before you can comment on or make changes to this bug.