Closed Bug 624187 (CVE-2011-0072) Opened 9 years ago Closed 9 years ago

Use after free after appending a frame/iframe element to a DOM tree with the NoScript add-on enabled.


(Core :: XPConnect, defect, critical)

Not set



Tracking Status
blocking2.0 --- betaN+
blocking1.9.2 --- .17+
status1.9.2 --- .17-fixed
blocking1.9.1 --- .19+
status1.9.1 --- .19-fixed


(Reporter: martybarbella, Assigned: mounir)


(Whiteboard: [sg:critical?][hardblocker] not sure if exploitable w/out addon)


(5 files, 2 obsolete files)

User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20101206 Ubuntu/10.04 (lucid) Firefox/3.6.13
Build Identifier: Mozilla Firefox 3.6.13

After appending a frame with a src of "#" to a title element with the NoScript add-on enabled, Firefox will usually crash. This is caused by a read of freed memory. The crash is usually occurring in nsDocShellEnumerator::GetNext(nsISupports**).

I have tested this in Firefox 3.6.13 with NoScript on Ubuntu 10.04 (64 bit) and Windows Vista (32 bit).

Reproducible: Sometimes

Steps to Reproduce:
1. Open the attached testcase, 1.html, in Firefox with the NoScript add-on enabled.
2. If a crash does not occur immediately, either refresh the page a few times, or close the browser. The crash after closing is extremely consistent, but refreshing the page a few times seems to do the trick.
Actual Results:  
The browser will either crash after loading the page, or at exit.

Expected Results:  
The particular script should be executed as expected, and the browser should not crash.

The html file that produces the crash, a stack trace using gdb, and output from valgrind will be attached after this bug is created. If I discover any other useful information about this bug, I will include it.
Ever confirmed: true
Whiteboard: [sg:critical?]
b? so the drivers see this, we still need confirmation whats affected and whats not
blocking1.9.1: --- → ?
blocking1.9.2: --- → ?
blocking2.0: --- → ?
Ben, can you have a look at this one?
Assignee: nobody → bent.mozilla
blocking2.0: ? → betaN+
Whiteboard: [sg:critical?] → [sg:critical?][hardblocker]
Actually, maybe Mounir could dig in here?
Assignee: bent.mozilla → mounir.lamouri
Is there a reason why nsDocShellEnumerator keeps weak reference to nsIDocShellTreeItem?
Cc:ing more people who might be able to answer Mounir's question above regarding nsDocShellEnumerator...
Uh.... no.  No reason.  And if fact, holding raw weak refs there is clearly unsafe.  The safe fix here (in terms of not leaking, etc) is probably to use an array of nsWeakPtrs.  The next-safer thing is to just make these strong refs and hope.  Note that docshell is not CCed.
Attached patch Patch v1 (obsolete) — Splinter Review
This is fixing the crash locally.
Attachment #503139 - Flags: review?(Olli.Pettay)
Attachment #503139 - Flags: review?(Olli.Pettay) → review+
Is this really sg:critical? is there any way to cause this crash in a default configuration?
blocking1.9.1: ? → needed
blocking1.9.2: ? → needed
Whiteboard: [sg:critical?][hardblocker] → [hardblocker]
This patch seems to turn some tests orange on the try server.
Attached patch Patch v1.1Splinter Review
This should pass the try server.
Attachment #503139 - Attachment is obsolete: true
Attachment #503508 - Flags: review?(Olli.Pettay)
Attached patch Inter diff (obsolete) — Splinter Review
Whiteboard: [hardblocker] → [hardblocker][passed try][needs review]
(In reply to comment #11)
> Is this really sg:critical? is there any way to cause this crash in a default
> configuration?

Possibly -- we use nsDocShellEnumerators in our own code (as do several add-ons in addition to NoScript) and could maybe get into this state. Assuming the worst back to [sg:critical?]
Whiteboard: [hardblocker][passed try][needs review] → [sg:critical?][hardblocker][passed try][needs review]
Attachment #503508 - Flags: review?(Olli.Pettay) → review+
Closed: 9 years ago
OS: Linux → All
Hardware: x86_64 → All
Resolution: --- → FIXED
Whiteboard: [sg:critical?][hardblocker][passed try][needs review] → [sg:critical?][hardblocker]
Target Milestone: --- → mozilla2.0b10
Version: unspecified → Trunk
For 1.9.2, the same patch will be usable.
For 1.9.1, it will require more work.
Whiteboard: [sg:critical?][hardblocker] → [sg:critical?][hardblocker][needs branch]
blocking1.9.1: needed → .18+
blocking1.9.2: needed → .15+
Attachment #503509 - Attachment is obsolete: true
Attachment #503508 - Flags: approval1.9.2.15?
Attached patch Patch for 1.9.1Splinter Review
I had to apply a part of
Re-asking a review to double-check.
Attachment #508166 - Flags: review?(Olli.Pettay)
Attachment #508166 - Flags: review?(Olli.Pettay) → review+
Attachment #508166 - Flags: approval1.9.1.18?
Comment on attachment 503508 [details] [diff] [review]
Patch v1.1

approved for, a=dveditz for release-drivers
Attachment #503508 - Flags: approval1.9.2.15? → approval1.9.2.15+
Comment on attachment 508166 [details] [diff] [review]
Patch for 1.9.1

approved for, a=dveditz for release-drivers
Attachment #508166 - Flags: approval1.9.1.18? → approval1.9.1.18+
Whiteboard: [sg:critical?][hardblocker][needs branch] → [sg:critical?][hardblocker]
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.
Alias: CVE-2011-0072
Whiteboard: [sg:critical?][hardblocker] → [sg:critical?][hardblocker] not sure if exploitable w/out addon
Group: core-security
Flags: sec-bounty+
You need to log in before you can comment on or make changes to this bug.