617247 - (CVE-2011-2373) Use after free (in nsXULProtypeScript?) when viewing xul document w/JS disabled

Status: RESOLVED FIXED

(Core :: XUL, defect)

Description

[Martin Barbella]

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]

Attachment: The file which when opened multiple times would result in the crash at exit.

Comment 2

[Martin Barbella]

Attachment: Stack traces and some additional information.

Comment 3

[Daniel Veditz [:dveditz]]

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

Sicking: jst says you're the best person to take an initial look at this

Comment 5

[Martin Barbella]

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]

Attachment: 3.6.13 stack trace with no add-ons and javascript disabled

Comment 7

[Martin Barbella]

Attachment: Output from valgrind in Firefox 3.6.13

Comment 8

[Johnny Stenback (:jst)]

Not blocking 2.0 on this as remote xul is disabled which lowers the severity of this bug on trunk.

Comment 9

[Martin Barbella]

Attachment: 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]

bp-65b7121c-cb43-43d3-98c6-e87532110119 (3.6.13)

Comment 12

[Daniel Veditz [:dveditz]]

Lowering to [sg:moderate] -- something's wrong here, but it's hard to call it exploitable at this point.

Comment 13

[Martin Barbella]

Attachment: 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]]

Clearing sg: markings for re-triage in light of recent comments

Comment 15

[Daniel Veditz [:dveditz]]

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

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

Attachment: 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]]

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

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

http://hg.mozilla.org/mozilla-central/rev/36089a888097

Comment 22

[Daniel Veditz [:dveditz]]

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

http://hg.mozilla.org/releases/mozilla-1.9.2/rev/55350f27b879

Comment 24

[Al Billings [:abillings - ex-MoCo]]

(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).