Bug 617247 (CVE-2011-2373)

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

RESOLVED FIXED

Status

()

defect
--
critical
RESOLVED FIXED
9 years ago
5 years ago

People

(Reporter: martybarbella, Assigned: peterv)

Tracking

({testcase, verified1.9.2})

unspecified
x86
Linux
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

9 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.
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?]
Reporter

Comment 5

9 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.
Product: Firefox → Core
QA Contact: firefox → toolkit
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]
Keywords: testcase
Reporter

Comment 9

9 years ago
Posted file 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

9 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

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

9 years ago
blocking1.9.2: ? → needed
Assignee

Updated

8 years ago
Assignee: jonas → peterv
Assignee

Comment 17

8 years ago
Posted patch v1Splinter Review
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

8 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.
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

8 years ago
http://hg.mozilla.org/mozilla-central/rev/36089a888097
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Assignee

Updated

8 years ago
Attachment #517259 - Flags: approval1.9.2.18?
Attachment #517259 - Flags: approval1.9.1.20?
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

8 years ago
http://hg.mozilla.org/releases/mozilla-1.9.2/rev/55350f27b879
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.