634986 - (CVE-2011-0065) Use-after-free vulnerability in OBJECT's mChannel (ZDI-CAN-1032)

Status: RESOLVED FIXED

(Core :: DOM: Core & HTML, defect, P1)

Description

[Brandon Sterne (:bsterne)]

The following was sent to [e-mail] today:

ZDI-CAN-1032: Mozilla Firefox OBJECT mChannel 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.

The specific flaw exists within the OnChannelRedirect method. When an OBJECT element has no mChannel assigned, it is possible to call the |OnChannelRedirect| method, setting a nearly arbitrary object as the channel in use. |mChannel| will become a dangling pointer, allowing an attacker to execute arbitrary code under the context of the user running the browser.

Version(s)  tested: Firefox 3.6.13
Platform(s) tested: Windows XP SP3

From content/base/src/nsObjectLoadingContent.cpp:

nsObjectLoadingContent::OnChannelRedirect(nsIChannel *aOldChannel,
nsIChannel *aNewChannel,
PRUint32 aFlags)
{
// If we're already busy with a new load, cancel the redirect
if (aOldChannel != mChannel) {
return NS_BINDING_ABORTED;
}

if (mClassifier) {
mClassifier->OnRedirect(aOldChannel, aNewChannel);
}

mChannel = aNewChannel;
return NS_OK;
}

When an OBJECT element (implementation of nsIChannelEventSink interface) has no |mChannel| assigned, it is possible to call the |OnChannelRedirect| method, setting a nearly arbitrary object as the channel in use. The problem is that |mChannel| is a weak reference (as defined in content/base/src/nsObjectLoadingContent.h) and will become a dangling pointer after the garbage collection cycle.


The dangling pointer can be utilized by setting the "data" attribute to our OBJECT. This will call the |LoadObject| method, and load our OBJECT.

nsObjectLoadingContent::LoadObject(nsIURI* aURI,
                                   PRBool aNotify,
                                   const nsCString& aTypeHint,
                                   PRBool aForceLoad)
{
  ...
  if (mChannel) {
    ...
    mChannel->Cancel(NS_BINDING_ABORTED);
    ...
  }
  ...
}

-- CREDIT --------------------------------------------------------------

This vulnerability was discovered by:
    * regenrecht

Comment 1

[Benjamin Smedberg]

bz, do you want this one?

Comment 2

[Boris Zbarsky [:bzbarsky]]

This is basically the same as bug 634983.  Content shouldn't be able to QI the <object> to these random interfaces.  And on trunk it can't.  We need to backport that change to branch.

Comment 3

[Boris Zbarsky [:bzbarsky]]

fwiw, this looks sg:critical to me.

Comment 4

[Boris Zbarsky [:bzbarsky]]

Actually, wait.  We just renamed the redirect function.  I can call asyncOnChannelRedirect from untrusted script fine on trunk....

I guess this is simple enough to fix by null-checking mChannel, though.

Comment 5

[Boris Zbarsky [:bzbarsky]]

Fwiw, I don't think 2.0 is unaffected.  It just needs a slightly different testcase to trigger.

I'll put up a patch tomorrow; I need to spend some time auditing the other stuff <object> and company implement.

Comment 6

[Asa Dotzler [:asa]]

If this affects 2.0, should we reconsider blocking there?

Comment 7

[Benjamin Smedberg]

Yeah :-(

Comment 8

[Damon Sicore (:damons)]

So, this is indeed confirmed critical?

Comment 9

[Benjamin Smedberg]

What does "confirmed critical" mean? We don't have a testcase which does an actual heap-smashing attack, but it is easy for content to trigger use-after-free, which pretty much guarantees that it can be weaponized.

Comment 10

[Boris Zbarsky [:bzbarsky]]

Sorry for the lag here; I did do the audit last week, and this plus the image loading content stuff from bug 634983 seem to be the only issues.

Comment 11

[Boris Zbarsky [:bzbarsky]]

Oh, and the long-term-correct fix is to stop allowing untrusted content to access this interface, but the upcoming patch will fix things for now.

Comment 12

[Boris Zbarsky [:bzbarsky]]

Attachment: fix

Comment 13

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 515685 [details] [diff] [review]
fix

This applies to both branches with only a bit of fuzz.

The other option is to implement the channel redirect listener on a non-scriptable helper object instead of on the element itself.  jst, let me know if you'd prefer that?

Comment 14

[Johnny Stenback (:jst)]

Comment on attachment 515685 [details] [diff] [review]
fix

I think this'll do for now, until we have bindings that lets us selectively expose stuff only where we intend to expose stuff...

Comment 15

[Johnny Stenback (:jst)]

Fix landed:

http://hg.mozilla.org/mozilla-central/rev/262b38ced70e

Comment 16

[LegNeato]

Comment on attachment 515685 [details] [diff] [review]
fix

approved for 1.9.2.15 and 1.9.1.18

Comment 17

[Boris Zbarsky [:bzbarsky]]

Pushed:
  http://hg.mozilla.org/releases/mozilla-1.9.2/rev/c24f21581d77
  http://hg.mozilla.org/releases/mozilla-1.9.1/rev/442b50206d50

Comment 18

[Daniel Veditz [:dveditz]]

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.