Beginning on October 25th, 2016, Persona will no longer be an option for authentication on BMO. For more details see Persona Deprecated.
Last Comment Bug 634983 - (CVE-2011-0066) Use-after-free vulnerability in OBJECT's mObserverList (ZDI-CAN-1033)
: Use-after-free vulnerability in OBJECT's mObserverList (ZDI-CAN-1033)
[sg:critical?] fixed by 604262
: verified1.9.1, verified1.9.2
Product: Core
Classification: Components
Component: DOM (show other bugs)
: 1.9.1 Branch
: All All
: -- normal (vote)
: ---
Assigned To: Johnny Stenback (:jst,
: Andrew Overholt [:overholt]
Depends on: 604262
Blocks: CVE-2011-0065
  Show dependency treegraph
Reported: 2011-02-17 11:19 PST by Brandon Sterne (:bsterne)
Modified: 2011-05-09 13:27 PDT (History)
10 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

Testcase showing the problem (won't crash or anything) (194 bytes, text/html)
2011-02-17 11:43 PST, Boris Zbarsky [:bz] (still a bit busy)
no flags Details

Description Brandon Sterne (:bsterne) 2011-02-17 11:19:23 PST
The following was reported to by ZDI:

ZDI-CAN-1033: Mozilla Firefox OBJECT mObserverList Remote Code Execution Vulnerabililty

-- 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 Firefox's handling of observer OBJECTs. If an observer OBJECT is removed from the mObserverList during an iteration of LOOP_OVER_OBSERVERS macro, one can heap spray over |mObserverList.mNext| and change the execution flow. This would allow the 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

As the OBJECT element implements nsIImageLoadingContent interface it is possible to register custom observer (implementing imgIDecoderObserver) and force our OBJECT removal during e.g.  onStartContainer| callback (other hooks are probably dangerous as well). That would also destroy object's observers linked list, |mObserverList|. If that happens during iteration of LOOP_OVER_OBSERVERS macro one can heap spray over |mObserverList.mNext| and change the execution flow.

From content/base/src/nsObjectLoadingContent.cpp:

// Macro to call some func on each observer.  This handles observers
// removing themselves.
#define LOOP_OVER_OBSERVERS(func_)                                      
    for (ImageObserver* observer = &mObserverList, *next; observer;     
         observer = next) {                                             
      next = observer->mNext;                                           
      if (observer->mObserver) {                                        

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

This vulnerability was discovered by:
    * regenrecht
Comment 1 Benjamin Smedberg [:bsmedberg] 2011-02-17 11:31:59 PST
This looks like it's saying "a Firefox extension could do something critically bad by implementing imgIDecoderObserver". That's not a security flaw in itself.
Comment 2 Boris Zbarsky [:bz] (still a bit busy) 2011-02-17 11:42:55 PST
Looks like on 3.6 untrusted content can call addObserver.  We don't allow that on trunk.
Comment 3 Boris Zbarsky [:bz] (still a bit busy) 2011-02-17 11:43:28 PST
Created attachment 513198 [details]
Testcase showing the problem (won't crash or anything)
Comment 4 Brandon Sterne (:bsterne) 2011-02-17 11:54:05 PST
Moving to 1.9.2 branch per comment 2.
Comment 5 Boris Zbarsky [:bz] (still a bit busy) 2011-02-17 12:09:55 PST
On trunk this was fixed in bug 604262.  We should probably just backport that patch.
Comment 6 Boris Zbarsky [:bz] (still a bit busy) 2011-02-17 12:10:16 PST
And I'd add a dep, but that bug is public, so....
Comment 7 Al Billings [:abillings] 2011-02-18 10:28:43 PST
Verified not to be affected on the 1.9.1 nightly.
Comment 8 Boris Zbarsky [:bz] (still a bit busy) 2011-02-18 10:39:31 PST
Al, how did you verify that exactly?  I would expect 1.9.1 to have this problem.
Comment 9 Boris Zbarsky [:bz] (still a bit busy) 2011-02-18 10:40:31 PST
To be clear, if you're using the attached testcase, the build is unaffected if opening the testcase shows an exception in the error console.  If there is no exception, then the build has this bug.
Comment 10 Brandon Sterne (:bsterne) 2011-02-18 10:47:17 PST
(In reply to comment #8)
> Al, how did you verify that exactly?  I would expect 1.9.1 to have this
> problem.

I believe he ran the testcase from bug 604262 in Firefox 3.5 and didn't see the crash.  Was that an incorrect verification?
Comment 11 Boris Zbarsky [:bz] (still a bit busy) 2011-02-18 11:24:07 PST
Yes.  The testcase in that bug doesn't crash in Firefox 3.6 either, for whatever reason, whereas this bug is clearly present in 3.6, right?
Comment 12 Al Billings [:abillings] 2011-02-18 17:02:54 PST
I checked the testcase in bug 604262 as Brandon asked me to do in triage today since I had a 1.9.1 system running at the moment. If that is wrong, we can change the 1.9.1 status. I didn't even look at 1.9.2 since we were in triage and wondering about 1.9.1.
Comment 13 Daniel Veditz [:dveditz] 2011-03-02 10:43:03 PST
There is no exception from the testcase in 3.5.18pre
Comment 14 Johnny Stenback (:jst, 2011-04-14 13:31:09 PDT
This is fixed for 1.9.2, moving to 1.9.1.
Comment 15 Al Billings [:abillings] 2011-04-21 17:08:05 PDT
This is fixed in Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv: Gecko/20110420 Firefox/3.5.19 for I see an exception in the error console: 

Error: uncaught exception: [Exception... "Component returned failure code: 0x80040111 (NS_ERROR_NOT_AVAILABLE) [nsIImageLoadingContent.addObserver]"  nsresult: "0x80040111 (NS_ERROR_NOT_AVAILABLE)"  location: "JS frame :: :: <TOP_LEVEL> :: line 5"  data: no]

This exception wasn't present in 1.9.19 build 1 (before we fixed this).

BTW, I see the same message in
Comment 16 Johnny Stenback (:jst, 2011-04-28 13:30:56 PDT
Marking fixed as this landed on all relevant branches, marking fixed.

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