User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:220.127.116.11) Gecko/20101027 Fedora/3.6.12-1.fc14 Firefox/3.6.12
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:18.104.22.168) 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).
Steps to Reproduce:
Source of test.xul (referred to in the steps to reproduce):
<?xml version="1.0" encoding="UTF-8"?>
var t = 1;
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).
As mentioned, it will either hang, result in a segmentation fault in free, or jump to an arbitrary address (very rarely).
Firefox should properly terminate.
Stack traces and test.xul will be attached.
Created attachment 495755 [details]
The file which when opened multiple times would result in the crash at exit.
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
Created attachment 497513 [details]
Created attachment 497514 [details]
Output from valgrind in Firefox 3.6.13
Not blocking 2.0 on this as remote xul is disabled which lowers the severity of this bug on trunk.
Created attachment 504293 [details]
Improved test case
Lowering to [sg:moderate] -- something's wrong here, but it's hard to call it exploitable at this point.
Created attachment 508047 [details]
Valgrind output from new test case in Firefox 3.6.13
Clearing sg: markings for re-triage in light of recent comments
... 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.
Created attachment 517259 [details] [diff] [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.
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.
Comment on attachment 517259 [details] [diff] [review]
Approved for 22.214.171.124, a=dveditz for release-drivers
(In reply to comment #9)
> Created attachment 504293 [details]
> Improved test case
> 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 126.96.36.199 using this testcase (Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:188.8.131.52pre) Gecko/20110609 Namoroka/3.6.18pre).