Note: There are a few cases of duplicates in user autocompletion which are being worked on.
Bug 624187 (CVE-2011-0072)

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

RESOLVED FIXED in mozilla2.0b10

Status

()

Core
XPConnect
--
critical
RESOLVED FIXED
7 years ago
3 years ago

People

(Reporter: Martin Barbella, Assigned: mounir)

Tracking

Trunk
mozilla2.0b10
Points:
---
Bug Flags:
sec-bounty +

Firefox Tracking Flags

(blocking2.0 betaN+, blocking1.9.2 .17+, status1.9.2 .17-fixed, blocking1.9.1 .19+, status1.9.1 .19-fixed)

Details

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

Attachments

(5 attachments, 2 obsolete attachments)

(Reporter)

Description

7 years ago
User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) 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 2.0.9.3 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.
(Reporter)

Comment 1

7 years ago
Created attachment 502284 [details]
Testcase which triggers the crash (referred to in the initial report as 1.html).
(Reporter)

Comment 2

7 years ago
Created attachment 502286 [details]
Stack trace and other information from gdb.
(Reporter)

Comment 3

7 years ago
Created attachment 502288 [details]
Output from valgrind (with flags --malloc-fill=aa --free-fill=bb --leak-check=no).

Updated

7 years ago
Status: UNCONFIRMED → NEW
Ever confirmed: true

Updated

7 years ago
Whiteboard: [sg:critical?]

Comment 4

7 years ago
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
(Assignee)

Comment 7

7 years ago
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...

Comment 9

7 years ago
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.
(Assignee)

Comment 10

7 years ago
Created attachment 503139 [details] [diff] [review]
Patch v1

This is fixing the crash locally.
Attachment #503139 - Flags: review?(Olli.Pettay)
(Assignee)

Updated

7 years ago
Status: NEW → ASSIGNED

Updated

7 years ago
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
status1.9.1: --- → wanted
status1.9.2: --- → wanted
Whiteboard: [sg:critical?][hardblocker] → [hardblocker]
(Assignee)

Comment 12

7 years ago
This patch seems to turn some tests orange on the try server.
(Assignee)

Comment 13

7 years ago
Created attachment 503508 [details] [diff] [review]
Patch v1.1

This should pass the try server.
Attachment #503139 - Attachment is obsolete: true
Attachment #503508 - Flags: review?(Olli.Pettay)
(Assignee)

Comment 14

7 years ago
Created attachment 503509 [details] [diff] [review]
Inter diff
(Assignee)

Updated

7 years ago
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]

Updated

7 years ago
Attachment #503508 - Flags: review?(Olli.Pettay) → review+
(Assignee)

Comment 16

7 years ago
Pushed:
http://hg.mozilla.org/mozilla-central/rev/e23b4fe4e09c
Status: ASSIGNED → RESOLVED
Last Resolved: 7 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
(Assignee)

Comment 17

7 years ago
For 1.9.2, the same patch will be usable.
For 1.9.1, it will require more work.
(Assignee)

Updated

7 years ago
Whiteboard: [sg:critical?][hardblocker] → [sg:critical?][hardblocker][needs branch]
blocking1.9.1: needed → .18+
blocking1.9.2: needed → .15+
(Assignee)

Updated

7 years ago
Attachment #503509 - Attachment is obsolete: true
(Assignee)

Updated

7 years ago
Attachment #503508 - Flags: approval1.9.2.15?
(Assignee)

Comment 19

7 years ago
Created attachment 508166 [details] [diff] [review]
Patch for 1.9.1

I had to apply a part of https://hg.mozilla.org/mozilla-central/rev/f2f8545e079b
Re-asking a review to double-check.
Attachment #508166 - Flags: review?(Olli.Pettay)

Updated

7 years ago
Attachment #508166 - Flags: review?(Olli.Pettay) → review+
(Assignee)

Updated

7 years ago
Attachment #508166 - Flags: approval1.9.1.18?
Comment on attachment 503508 [details] [diff] [review]
Patch v1.1

approved for 1.9.2.15, 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 1.9.1.18, a=dveditz for release-drivers
Attachment #508166 - Flags: approval1.9.1.18? → approval1.9.1.18+
(Assignee)

Comment 22

7 years ago
http://hg.mozilla.org/releases/mozilla-1.9.1/rev/a47c1882ad1d
http://hg.mozilla.org/releases/mozilla-1.9.2/rev/04c4b77a3b8f
status1.9.1: wanted → .18-fixed
status1.9.2: wanted → .15-fixed
(Assignee)

Updated

7 years ago
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.