Last Comment Bug 634986 - (CVE-2011-0065) Use-after-free vulnerability in OBJECT's mChannel (ZDI-CAN-1032)
: Use-after-free vulnerability in OBJECT's mChannel (ZDI-CAN-1032)
[sg:critical?][hardblocker][has patch]
Product: Core
Classification: Components
Component: DOM (show other bugs)
: Trunk
: All All
: P1 normal (vote)
: mozilla2.0
Assigned To: Boris Zbarsky [:bz] (still a bit busy)
: Andrew Overholt [:overholt]
Depends on: CVE-2011-0066
  Show dependency treegraph
Reported: 2011-02-17 11:26 PST by Brandon Sterne (:bsterne)
Modified: 2011-05-09 13:24 PDT (History)
11 users (show)
bzbarsky: in‑testsuite?
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

fix (1.23 KB, patch)
2011-02-28 11:30 PST, Boris Zbarsky [:bz] (still a bit busy)
jst: review+
christian: approval1.9.2.17+
christian: approval1.9.1.19+
Details | Diff | Splinter Review

Description Brandon Sterne (:bsterne) 2011-02-17 11:26:49 PST
The following was sent to 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) {

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) {

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

This vulnerability was discovered by:
    * regenrecht
Comment 1 Benjamin Smedberg [:bsmedberg] 2011-02-17 11:29:08 PST
bz, do you want this one?
Comment 2 Boris Zbarsky [:bz] (still a bit busy) 2011-02-17 11:46:54 PST
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 [:bz] (still a bit busy) 2011-02-17 11:47:20 PST
fwiw, this looks sg:critical to me.
Comment 4 Boris Zbarsky [:bz] (still a bit busy) 2011-02-17 11:52:21 PST
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 [:bz] (still a bit busy) 2011-02-17 20:39:44 PST
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] 2011-02-27 12:23:36 PST
If this affects 2.0, should we reconsider blocking there?
Comment 7 Benjamin Smedberg [:bsmedberg] 2011-02-28 06:06:23 PST
Yeah :-(
Comment 8 Damon Sicore (:damons) 2011-02-28 10:45:56 PST
So, this is indeed confirmed critical?
Comment 9 Benjamin Smedberg [:bsmedberg] 2011-02-28 10:48:16 PST
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 [:bz] (still a bit busy) 2011-02-28 11:22:22 PST
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 [:bz] (still a bit busy) 2011-02-28 11:24:25 PST
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 [:bz] (still a bit busy) 2011-02-28 11:30:11 PST
Created attachment 515685 [details] [diff] [review]
Comment 13 Boris Zbarsky [:bz] (still a bit busy) 2011-02-28 11:33:03 PST
Comment on attachment 515685 [details] [diff] [review]

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, 2011-02-28 13:59:12 PST
Comment on attachment 515685 [details] [diff] [review]

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, 2011-02-28 14:26:24 PST
Fix landed:
Comment 16 christian 2011-03-02 10:47:16 PST
Comment on attachment 515685 [details] [diff] [review]

approved for and
Comment 18 Daniel Veditz [:dveditz] 2011-03-04 10:14:42 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.

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