Last Comment Bug 617247 - (CVE-2011-2373) Use after free (in nsXULProtypeScript?) when viewing xul document w/JS disabled
(CVE-2011-2373)
: Use after free (in nsXULProtypeScript?) when viewing xul document w/JS disabled
Status: RESOLVED FIXED
[sg:critical?] (if JS disabled)
: testcase, verified1.9.2
Product: Core
Classification: Components
Component: XUL (show other bugs)
: unspecified
: x86 Linux
: -- critical (vote)
: ---
Assigned To: Peter Van der Beken [:peterv]
:
Mentors:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2010-12-06 20:17 PST by Martin Barbella
Modified: 2014-07-22 13:04 PDT (History)
9 users (show)
rforbes: sec‑bounty+
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
fixed
-
.18+
.18-fixed


Attachments
The file which when opened multiple times would result in the crash at exit. (204 bytes, application/vnd.mozilla.xul+xml)
2010-12-06 20:18 PST, Martin Barbella
no flags Details
Stack traces and some additional information. (3.57 KB, text/plain)
2010-12-06 20:19 PST, Martin Barbella
no flags Details
3.6.13 stack trace with no add-ons and javascript disabled (6.66 KB, text/plain)
2010-12-14 09:21 PST, Martin Barbella
no flags Details
Output from valgrind in Firefox 3.6.13 (35.13 KB, text/plain)
2010-12-14 09:23 PST, Martin Barbella
no flags Details
Improved test case (2.21 KB, text/html)
2011-01-16 12:57 PST, Martin Barbella
no flags Details
Valgrind output from new test case in Firefox 3.6.13 (33.48 KB, text/plain)
2011-01-28 17:00 PST, Martin Barbella
no flags Details
v1 (1.13 KB, patch)
2011-03-06 07:46 PST, Peter Van der Beken [:peterv]
jonas: review+
dveditz: approval1.9.2.18+
Details | Diff | Splinter Review

Description Martin Barbella 2010-12-06 20:17:05 PST
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.
Comment 1 Martin Barbella 2010-12-06 20:18:48 PST
Created attachment 495755 [details]
The file which when opened multiple times would result in the crash at exit.
Comment 2 Martin Barbella 2010-12-06 20:19:51 PST
Created attachment 495756 [details]
Stack traces and some additional information.
Comment 3 Daniel Veditz [:dveditz] 2010-12-07 13:45:31 PST
So you've seen this problem with add-ons OTHER than NoScript (less reliably), and never without addons or in safe-mode?
Comment 4 Daniel Veditz [:dveditz] 2010-12-07 13:47:40 PST
Sicking: jst says you're the best person to take an initial look at this
Comment 5 Martin Barbella 2010-12-14 09:19:04 PST
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.
Comment 6 Martin Barbella 2010-12-14 09:21:09 PST
Created attachment 497513 [details]
3.6.13 stack trace with no add-ons and javascript disabled
Comment 7 Martin Barbella 2010-12-14 09:23:04 PST
Created attachment 497514 [details]
Output from valgrind in Firefox 3.6.13
Comment 8 Johnny Stenback (:jst, jst@mozilla.com) 2011-01-05 15:55:08 PST
Not blocking 2.0 on this as remote xul is disabled which lowers the severity of this bug on trunk.
Comment 9 Martin Barbella 2011-01-16 12:57:09 PST
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 timeless 2011-01-19 13:46:51 PST
bp-65b7121c-cb43-43d3-98c6-e87532110119 (3.6.13)
Comment 12 Daniel Veditz [:dveditz] 2011-01-28 12:31:51 PST
Lowering to [sg:moderate] -- something's wrong here, but it's hard to call it exploitable at this point.
Comment 13 Martin Barbella 2011-01-28 17:00:55 PST
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?
Comment 14 Daniel Veditz [:dveditz] 2011-01-31 10:30:49 PST
Clearing sg: markings for re-triage in light of recent comments
Comment 15 Daniel Veditz [:dveditz] 2011-02-02 10:14:27 PST
... might still be "moderate" if it only happens with JS disabled, which in practice is rare (but less rare amongst security-aware users).
Comment 16 Daniel Veditz [:dveditz] 2011-02-03 13:19:07 PST
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.
Comment 17 Peter Van der Beken [:peterv] 2011-03-06 07:46:52 PST
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.
Comment 18 Peter Van der Beken [:peterv] 2011-03-06 08:15:22 PST
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.
Comment 20 Daniel Veditz [:dveditz] 2011-03-25 14:22:57 PDT
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.
Comment 21 Peter Van der Beken [:peterv] 2011-04-02 08:19:27 PDT
http://hg.mozilla.org/mozilla-central/rev/36089a888097
Comment 22 Daniel Veditz [:dveditz] 2011-05-04 10:53:58 PDT
Comment on attachment 517259 [details] [diff] [review]
v1

Approved for 1.9.2.18, a=dveditz for release-drivers
Comment 23 Peter Van der Beken [:peterv] 2011-06-01 13:36:58 PDT
http://hg.mozilla.org/releases/mozilla-1.9.2/rev/55350f27b879
Comment 24 Al Billings [:abillings] 2011-06-09 12:24:39 PDT
(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).

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