Closed Bug 484320 (CVE-2009-1044) Opened 12 years ago Closed 12 years ago

XUL <tree> _moveToEdgeShift garbage-collection exploit (zdi-can-465)


(Core :: XUL, defect, P1)






(Reporter: dveditz, Assigned: smaug)


(5 keywords, Whiteboard: [sg:critical] ZDI CanSecWest 2009 bug; exploit is post 1.8-branch)


(1 file)

Placeholder for Pwn2Own bug found in Firefox at CanSecWest 2009
Alias: ZDI-CAN-465
Severity: normal → critical
Component: Security → XUL
Keywords: crash
QA Contact: toolkit → xptoolkit.widgets
Summary: ZDI CanSecWest bug (ZDI-CAN-465) → XUL <tree> _moveToEdgeShift garbage-collection exploit
Whiteboard: [sg:critical] → [sg:critical] ZDI CanSecWest bug
jst said to start with Neil. Since this is a high profile bug (Firefox cracked during a public hacking contest) we need to focus on it. If we had a fix I'd like to shoehorn it into even though we're past codefreeze (April release) but May's is more realistic. Needs to make 3.5b4.
Assignee: nobody → enndeakin
Flags: wanted1.9.0.x+
Flags: blocking1.9.1?
Flags: blocking1.9.0.9?
Flags: blocking1.9.0.8?
Windows and OSX stacks look quite different :/

Does this crash on trunk/1.9.1?
If not, my guess is that bug 430214 fixed this.
Especially this
It changed nsTreeSelection::FireOnSelectHandler to asynchronous.
(In reply to comment #4)
> Does this crash on trunk/1.9.1?
I was told it does crash, so something else then...
Here's yet a different Windows crash, in Shiretoko rather than 3.0.7

what does nsTextServicesDocument::InitWithEditor have to do with this testcase?
This sounds like memory stomping somewhere. valgrind might shed some light.
Attached file safer starting point
Here's a safer starting point. The guts of the testcase are still in the, but this copy of hold.html has the shellcode replaced with %u4141...
Yeah, need to fix this for the reasons stated above. Neil: are you the right dude to be looking at this?
Flags: blocking1.9.1? → blocking1.9.1+
Priority: -- → P1
Attached patch patchSplinter Review
Could someone please test this on non-linux.
I haven't yet checked if timer code should be actually fixed.
I tested this on 1.9.1 / 64bit linux / debug build
(In reply to comment #11)
> I haven't yet checked if timer code should be actually fixed.
But for 1.9.0 the patch might be the safest fix - shouldn't cause regressions.
Note that I never got the PoC to crash in a debug build so the patch will have to be verified in an opt build.
Comment on attachment 368977 [details] [diff] [review]

So, InitWithFuncCallback is used, passing this is unsafe *unless*
timer is canceled before deleting this.
Attachment #368977 - Flags: superreview?(mrbkap)
Attachment #368977 - Flags: review?(dveditz)
Assignee: enndeakin → Olli.Pettay
Comment on attachment 368977 [details] [diff] [review]

This makes sense. Good catch!
Attachment #368977 - Flags: superreview?(mrbkap) → superreview+
Comment on attachment 368977 [details] [diff] [review]


Tested in opt builds and this patch stops the mac crashes I was seeing (I never got a debug build to crash). Since I was seeing completely different stacks on windows I'd like to verify this there as well.
Attachment #368977 - Flags: review?(dveditz)
Attachment #368977 - Flags: review+
Attachment #368977 - Flags: approval1.9.1?
Attachment #368977 - Flags: approval1.9.0.8?
Comment on attachment 368977 [details] [diff] [review]

Does this have to go in on trunk and branch at the same time, or can we bake it there a bit first? Either way, it's a blocker, so doesn't need a191.
Attachment #368977 - Flags: approval1.9.1?

This does still need verification on windows.
Closed: 12 years ago
Keywords: fixed1.9.1
Resolution: --- → FIXED
The patch does fix the crash also on 1.9.0 (tested on linux).
The patch seems to fix the crash for me in my trunk debug build on windows XP.
Flags: blocking1.9.0.9?
Flags: blocking1.9.0.8?
Flags: blocking1.9.0.8+
Comment on attachment 368977 [details] [diff] [review]

Approved for, a=dveditz for release-drivers

Can you land this ASAP? we're well beyond code-freeze for
Attachment #368977 - Flags: approval1.9.0.8? → approval1.9.0.8+
Checking in layout/xul/base/src/tree/src/nsTreeSelection.cpp;
/cvsroot/mozilla/layout/xul/base/src/tree/src/nsTreeSelection.cpp,v  <--  nsTreeSelection.cpp
new revision: 1.59; previous revision: 1.58
Keywords: fixed1.9.0.8
Stops the crash on windows for me as well (tested shiretoko tinderbox build).
Olli: Does this bug affect 1.8? We're taking it in a firedrilled Firefox 3.0.8, so if so, we'll want to get a patch ready for the distros to take.
I can't reproduce the crash on 1.8.1, but I don't know why.
The code is the same.

The patch applies to 1.8.1 too (just need to use --fuzz=3)
Ah, 1.8.1 doesn't seem to have bug 362680. So reproducing would need some
changes to the testcase.
Keywords: fixed1.9.0.8
Flags: blocking1.9.0.8+
1.8.0 is in the same boat as above.  patch applies with fuzz=3, but testcase doesn't work
Should this have a crashtest?
Not yet, IMO. As far as I know the testcase is not public yet.
This is CVE-2009-1044
(In reply to comment #31)
> This is CVE-2009-1044
But the testcase isn't public, right?
No, MITRE assigned this based only off of the announcement from CanSecWest.  If you look at the CVE id information:

There is nothing of consequence there.  It's just a placeholder.
Alias: ZDI-CAN-465 → CVE-2009-1044
Summary: XUL <tree> _moveToEdgeShift garbage-collection exploit → XUL <tree> _moveToEdgeShift garbage-collection exploit (zdi-can-465)
Verified using: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv: Gecko/2009032608 Firefox/3.0.8

Also verified with Fx308 on Ubuntu 8.10 and Windows XP and Vista.

Mac Fx307 crashed with the test case.

Fx307 did not crash on Linux nor Windows(xp/vista) VMs for me. Fx307 did crash on a windows installation running on hardware, however.
Group: core-security
Although the exploit doesn't affect the 1.8 branch because it uses functionality that doesn't exist there, we should take this small patch just in case there's another way to end up with a dangling selection timer.
Flags: wanted1.8.1.x+
Flags: wanted1.8.0.x?
Whiteboard: [sg:critical] ZDI CanSecWest bug → [sg:critical] ZDI CanSecWest bug; exploit is post 1.8-branch
Verified for with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/2009040206 GranParadiso/3.0.9pre (.NET CLR 3.5.30729) and Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv: Gecko/2009040204 GranParadiso/3.0.9pre.

Verified for 1.9.1 with Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b4pre) Gecko/20090402 Shiretoko/3.5b4pre.
Attachment #368977 - Flags:
Attachment #368977 - Flags:
Comment on attachment 368977 [details] [diff] [review]

code is the same, so it seems it makes sense to take this.
Flags: wanted1.8.0.x?
Attachment #368977 - Flags: →
Comment on attachment 368977 [details] [diff] [review]

a=asac for 1.8.0
Attachment #368977 - Flags: →
fix checked into the 1.8.1 branch
Checking in layout/xul/base/src/tree/src/nsTreeSelection.cpp;
/cvsroot/mozilla/layout/xul/base/src/tree/src/nsTreeSelection.cpp,v  <--  nsTreeSelection.cpp
new revision:; previous revision: 1.47
Keywords: fixed1.8.1.22
Whiteboard: [sg:critical] ZDI CanSecWest bug; exploit is post 1.8-branch → [sg:critical] ZDI CanSecWest 2009 bug; exploit is post 1.8-branch
You need to log in before you can comment on or make changes to this bug.