Bug 617247 (CVE-2011-2373)

Use after free (in nsXULProtypeScript?) when viewing xul document w/JS disabled

RESOLVED FIXED

Status

()

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

People

(Reporter: Martin Barbella, Assigned: peterv)

Tracking

({testcase, verified1.9.2})

unspecified
x86
Linux
testcase, verified1.9.2
Points:
---
Bug Flags:
sec-bounty +

Firefox Tracking Flags

(firefox5 fixed, blocking2.0 -, blocking1.9.2 .18+, status1.9.2 .18-fixed)

Details

(Whiteboard: [sg:critical?] (if JS disabled))

Attachments

(7 attachments)

(Reporter)

Description

7 years ago
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.12) Gecko/20101027 Fedora/3.6.12-1.fc14 Firefox/3.6.12
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.12) Gecko/20101027 Fedora/3.6.12-1.fc14 Firefox/3.6.12

Under certain conditions, when accessing a xul document in Mozilla Firefox, it appears that some memory is freed which could potentially still be in use. This results in a use after free vulnerability. This issue is highly sensitive to installed add-ons, which makes reliable exploitation rather difficult, but it can be fairly reliably exploited utilizing the popular NoScript add-on. This could potentially also affect other products such as Thunderbird (crashing in XPCOM code), but I have not found a way to demonstrate this. I am able to reproduce this in Firefox rather easily by opening many xul documents when scripts are not allowed for the domain that they are hosted on, then closing the browser. It tends to result in either a hang at exit (which is only easy to notice if running Firefox from a terminal), or result in a segmentation fault. It appears not to have the problem with hanging when running Firefox with gdb (it will simply segfault). I have tested this in both Windows Vista and Linux (Fedora 14).

Reproducible: Sometimes

Steps to Reproduce:
Source of test.xul (referred to in the steps to reproduce):
<?xml version="1.0" encoding="UTF-8"?>
<page xmlns="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul">
  <script type="application/javascript"><![CDATA[
    var t = 1;
  ]]></script>
</page>

1. Install Firefox 3.6.12 and the NoScript add-on.
2. Run firefox attached to a debugger (firefox -g) and open test.xul multiple times (approximately 5). It could be placed on a web server, but was not in this example. 
3. Make sure that NoScript has scripts disabled for the current domain. This may not be necessary, but was done during my tests.
4. Close firefox. When running firefox without gdb, it seems to hang at exit more often than it results in a segmentation fault.
5. Note that (most of the time) there will be a segmentation fault in free, which seems to be caused by a double free. In rare cases, depending on other open pages and various other factors, a function pointer will be overwritten when other memory is allocated with the address of the freed memory. This will result in a jump to an arbitrary location in memory at exit (in my tests, usually 0x1).
Actual Results:  
As mentioned, it will either hang, result in a segmentation fault in free, or jump to an arbitrary address (very rarely).

Expected Results:  
Firefox should properly terminate.

Stack traces and test.xul will be attached.
(Reporter)

Comment 1

7 years ago
Created attachment 495755 [details]
The file which when opened multiple times would result in the crash at exit.
(Reporter)

Comment 2

7 years ago
Created attachment 495756 [details]
Stack traces and some additional information.
So you've seen this problem with add-ons OTHER than NoScript (less reliably), and never without addons or in safe-mode?
Sicking: jst says you're the best person to take an initial look at this
Assignee: nobody → jonas
Whiteboard: [sg:critical?]
blocking2.0: --- → betaN+
(Reporter)

Comment 5

7 years ago
After poking around at this a little bit more, it appears that NoScript/add-ons in general are not necessary. It works the same way described previously if javascript is disabled in the preferences dialog. I am attaching an additional stack trace from a crash in Firefox 3.6.13 with no add-ons and javascript disabled through preferences, as well as valgrind output which seems to suggest that the premature free is occurring in the nsXULProtypeScript destructor.
(Reporter)

Comment 6

7 years ago
Created attachment 497513 [details]
3.6.13 stack trace with no add-ons and javascript disabled
(Reporter)

Comment 7

7 years ago
Created attachment 497514 [details]
Output from valgrind in Firefox 3.6.13
Component: Security → Security
Product: Firefox → Core
QA Contact: firefox → toolkit

Updated

7 years ago
blocking2.0: betaN+ → -
Not blocking 2.0 on this as remote xul is disabled which lowers the severity of this bug on trunk.
Whiteboard: [sg:critical?] → [sg:critical?][sg:needinfo]
status1.9.2: --- → wanted
Keywords: testcase
(Reporter)

Comment 9

7 years ago
Created attachment 504293 [details]
Improved test case

I have attached an improved test case. It still requires that javascript is disabled, but it seems to work more reliably. It is an HTML document which creates multiple iframes with a src of the previous test case Base64 encoded. Without a debugger attached it still has a tendency to hang at exit rather than crashing, but it isn't quite as bad as before.

Comment 10

7 years ago
bp-65b7121c-cb43-43d3-98c6-e87532110119 (3.6.13)
Status: UNCONFIRMED → NEW
Component: Security → XUL
Ever confirmed: true
QA Contact: toolkit → xptoolkit.widgets
blocking1.9.2: --- → ?
Lowering to [sg:moderate] -- something's wrong here, but it's hard to call it exploitable at this point.
Whiteboard: [sg:critical?][sg:needinfo] → [sg:moderate][sg:needinfo]
(Reporter)

Comment 13

7 years ago
Created attachment 508047 [details]
Valgrind output from new test case in Firefox 3.6.13

With the new test case the output from valgrind seems to look about the same as before. Invalid reads and writes in recently freed memory, and an invalid delete on an address that has already been freed. It was produced with all add-ons and javascript disabled. What else would you want to see to demonstrate that the issue is exploitable?
Clearing sg: markings for re-triage in light of recent comments
Summary: Use after free when viewing xul document with certain add-ons. → Use after free (in nsXULProtypeScript?) when viewing xul document w/JS disabled
Whiteboard: [sg:moderate][sg:needinfo]
... might still be "moderate" if it only happens with JS disabled, which in practice is rare (but less rare amongst security-aware users).
back to sg:critical for now, "worst case". Won't know for sure until we find the true cause. We might still bump it down if JS is required in all cases, rather than just something that helps us find it in this particular testcase.
Whiteboard: [sg:critical?]

Updated

7 years ago
blocking1.9.2: ? → needed
(Assignee)

Updated

6 years ago
Assignee: jonas → peterv
(Assignee)

Comment 17

6 years ago
Created attachment 517259 [details] [diff] [review]
v1

UnlinkJSObjects only calls DropScriptObjects if mScriptObject.mObject is non-null, so we shouldn't call HoldScriptObjects if we're setting mScriptObject.mObject to null since we'll never call DropScriptObjects and we'll end up accessing freed objects.
Attachment #517259 - Flags: review?(jonas)
(Assignee)

Comment 18

6 years ago
This relies on remote XUL and on JS being disabled (either through prefs or an addon) because in that case the compilation will return a success code with a null script object. I don't think you can trigger it in any other way.
Attachment #517259 - Flags: review?(jonas) → review+
peterv: worth fixing on m-c? we don't have -remote- XUL, but might this affect our own internal (or add-on) XUL? Not a security bug in those cases, just bugs.
Whiteboard: [sg:critical?] → [sg:critical?] (if JS disabled)
(Assignee)

Comment 21

6 years ago
http://hg.mozilla.org/mozilla-central/rev/36089a888097
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
(Assignee)

Updated

6 years ago
Attachment #517259 - Flags: approval1.9.2.18?
Attachment #517259 - Flags: approval1.9.1.20?
status-firefox5: --- → fixed
Comment on attachment 517259 [details] [diff] [review]
v1

Approved for 1.9.2.18, a=dveditz for release-drivers
Attachment #517259 - Flags: approval1.9.2.18?
Attachment #517259 - Flags: approval1.9.2.18+
Attachment #517259 - Flags: approval1.9.1.20?
blocking1.9.2: needed → .18+
Whiteboard: [sg:critical?] (if JS disabled) → [sg:critical?] (if JS disabled) needs 1.9.2 landing
(Assignee)

Comment 23

6 years ago
http://hg.mozilla.org/releases/mozilla-1.9.2/rev/55350f27b879
status1.9.2: wanted → .18-fixed
Whiteboard: [sg:critical?] (if JS disabled) needs 1.9.2 landing → [sg:critical?] (if JS disabled)
(In reply to comment #9)
> Created attachment 504293 [details]
> Improved test case
> 
> I have attached an improved test case. It still requires that javascript is
> disabled, but it seems to work more reliably. It is an HTML document which
> creates multiple iframes with a src of the previous test case Base64
> encoded. Without a debugger attached it still has a tendency to hang at exit
> rather than crashing, but it isn't quite as bad as before.

Verified fixed in 1.9.2.18 using this testcase (Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18pre) Gecko/20110609 Namoroka/3.6.18pre).
Keywords: verified1.9.2
Alias: CVE-2011-2373
Group: core-security
Flags: sec-bounty+
You need to log in before you can comment on or make changes to this bug.