Last Comment Bug 533000 - (CVE-2010-0160) Web Worker Array Handling Heap Corruption Vulnerability (ZDI-CAN-624)
(CVE-2010-0160)
: Web Worker Array Handling Heap Corruption Vulnerability (ZDI-CAN-624)
Status: RESOLVED FIXED
[sg:critical?] See comment 18, remain...
: crash, verified1.9.1
Product: Core
Classification: Components
Component: DOM (show other bugs)
: Trunk
: x86 Windows Vista
: -- critical (vote)
: mozilla1.9.2
Assigned To: Nobody; OK to take it and work on it
:
Mentors:
Depends on: 531222 534051
Blocks:
  Show dependency treegraph
 
Reported: 2009-12-04 14:08 PST by Daniel Veditz [:dveditz]
Modified: 2010-09-15 16:09 PDT (History)
13 users (show)
mbeltzner: blocking1.9.2-
dveditz: wanted1.9.0.x-
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
final+
final-fixed
.8+
.8-fixed


Attachments

Description Daniel Veditz [:dveditz] 2009-12-04 14:08:36 PST
Received this from ZDI today, from the same guy who found bug 514554:

ZDI-CAN-624: Mozilla Firefox Web Worker Array Handling Heap Corruption Vulnerability

-- ABSTRACT ------------------------------------------------------------

TippingPoint has identified a vulnerability affecting the following 
products:

    Mozilla Firefox 3.5.x

-- VULNERABILITY DETAILS -----------------------------------------------

This vulnerability allows remote attackers to execute arbitrary code on
vulnerable installations of Mozilla Firefox. User interaction is
required to exploit this vulnerability in that the target must visit a
malicious page.

The specific flaw exists within the implementation of web worker
threads. Due to mishandling the array data type while processing posted
messages, a web worker thread can be made to corrupt heap memory. An
attacker can exploit this vulnerability to execute arbitrary code under
the context of the user running the browser.

Version(s)  tested: Firefox 3.5
Platform(s) tested: Vista 32, 64

The faulty code resides within the handling of postMessage method calls.
Specifically, the passing of an array argument to a postMessage call as
follows:

var sprayContainer = new Array();
var worker = new Worker("crash.js");

for (i=0; i<600; i++)  
{
    worker.postMessage(sprayContainer[i]);
}

--------------------------------------------

where crash.js contains:

--------------------------------------------

onmessage = function(event){
var worker = new Worker("workCRASH1.js");
	worker.onmessage = function(event)
	{	
		worker.postMessage(event.data);
		postMessage(event.data);
	};

worker.postMessage(event.data);
postMessage(event.data);
}

-- CREDIT --------------------------------------------------------------

This vulnerability was discovered by:
    * Orlando Barrera II, SecTheory
Comment 1 Daniel Veditz [:dveditz] 2009-12-04 15:07:01 PST
I've asked for a copy of the "workCRASH1.js" script
Comment 2 Ben Turner (not reading bugmail, use the needinfo flag!) 2009-12-06 19:43:35 PST
I first assumed that 'workCRASH1.js' was a typo and should have been 'crash.js' but I'm unable to get any crash (or any kind of misbehavior at all) with that substitution.
Comment 3 Samuel Sidler (old account; do not CC) 2009-12-06 20:20:25 PST
We don't have workers on 1.9.0, so this shouldn't block there.
Comment 4 Reed Loden [:reed] (use needinfo?) 2009-12-06 23:09:43 PST
(In reply to comment #3)
> We don't have workers on 1.9.0, so this shouldn't block there.

We blocked on 1.9.0 for bug 514554 (for reasons in c3, c12, c13). Why is this different?
Comment 5 Ben Turner (not reading bugmail, use the needinfo flag!) 2009-12-07 17:08:32 PST
(In reply to comment #4)
> We blocked on 1.9.0 for bug 514554 (for reasons in c3, c12, c13). Why is this
> different?

That was a crash in XPConnect so the bug did exist on 1.9.0. This one... Well, I can't reproduce yet so I don't know where the problem lives.
Comment 6 Mike Beltzner [:beltzner, not reading bugmail] 2009-12-08 11:30:47 PST
Thanks, Reed, for setting all the blocking flags. Since we can't reproduce this at the moment, not blocking 1.9.2.
Comment 7 Reed Loden [:reed] (use needinfo?) 2009-12-08 13:36:14 PST
(In reply to comment #6)
> Thanks, Reed, for setting all the blocking flags. Since we can't reproduce this
> at the moment, not blocking 1.9.2.

We can't reproduce it because we don't have the entire testcase, which happens more often than not, sadly. ZDI has a good record of reporting real sg:critical bugs, so it may be wise to pre-emptively block on just that history, as it ensures we continue working to get the complete testcase and get this fixed.
Comment 8 Daniel Veditz [:dveditz] 2009-12-09 16:44:35 PST
The file contents I received were identical to crash.js -- I will double-check that they sent the correct file since Ben tried that and couldn't reproduce.
Comment 9 Ben Turner (not reading bugmail, use the needinfo flag!) 2009-12-10 13:53:42 PST
Aha, I couldn't get this to crash before, but today seems to be my lucky day.

3.5.3: bp-2d41cafb-867a-4882-9070-538092091210
3.5.4: bp-bb770e6b-4b8f-42f1-a600-5fbfe2091210
3.5.5: bp-b2e31d18-1a84-436e-ab82-4559f2091210
Comment 10 Ben Turner (not reading bugmail, use the needinfo flag!) 2009-12-14 13:25:47 PST
Possible causes include bug 534051 and bug 534341. Both are now fixed, but I was still able to get another crash on 3.5.6pre even with those applied. Leaving this open a little while longer.
Comment 11 Ben Turner (not reading bugmail, use the needinfo flag!) 2009-12-14 13:27:03 PST
Oh, and as far as I can tell any remaining bug is related to the cycle collector and has nothing to do with arrays or passing uninitialized array values to workers as claimed in comment 0.
Comment 12 Daniel Veditz [:dveditz] 2009-12-14 14:19:36 PST
Ben: does this also crash in 3.6 and trunk, or was it fixed in those versions?
Comment 13 Daniel Veditz [:dveditz] 2009-12-14 14:21:44 PST
The 1.9.0 branch does not include web workers. The testcase here definitely does not affect it. The underlying flaw may not be in workers and may or may not exist in 1.9.0, but it doesn't need to block until we know that's the case and that it's likely to be exploitable there.
Comment 14 Daniel Veditz [:dveditz] 2009-12-15 13:32:02 PST
Created attachment 417764 [details]
PoC files
Comment 15 Peter Van der Beken [:peterv] - away till Aug 1st 2009-12-16 10:50:20 PST
(In reply to comment #11)
> Oh, and as far as I can tell any remaining bug is related to the cycle
> collector and has nothing to do with arrays or passing uninitialized array
> values to workers as claimed in comment 0.

I figured out that that crash would be fixed by taking bug 502687 on branches. Nominated those for blocking.

No idea if that fixes all the remaining crashes that this triggers.
Comment 16 Daniel Veditz [:dveditz] 2009-12-18 11:13:12 PST
I'll move the 1.9.0 blocking flags over to bug 502687 since there's no way to test/verify this one on that branch.
Comment 17 Johnny Stenback (:jst, jst@mozilla.com) 2010-01-12 18:15:29 PST
Seems like bug 534051, bug 534341, and bug 502687 have all been fixed for 1.9.1.8, is there anything left to do for 1.9.1.8 here?
Comment 18 Ben Turner (not reading bugmail, use the needinfo flag!) 2010-01-19 13:28:41 PST
The testcase still crashes 1.9.1.8pre (with those three bugs already fixed), but it's an unhandled exception generated by a failing malloc (OOM). Not exploitable, and jst+sicking recommend not trying to enforce nothrow malloc here.
Comment 19 Ben Turner (not reading bugmail, use the needinfo flag!) 2010-01-19 13:29:15 PST
WONTFIX based on that.
Comment 20 Jonas Sicking (:sicking) PTO Until July 5th 2010-01-19 14:31:24 PST
I just want to point out that the actual Heap Corruption issue is FIXED as part of bug 534051, bug 534341, and bug 502687. If I understand correctly.

The issue that bent was referring to in comment 18, is how we handle out-of-memory. Currently we crash in a non-exploitable way, which is deemed ok at this time.

So it might be more correct to say that this bug is WORKSFORME or FIXED, given that Heap Corruption issue described in the summary has indeed been fixed.

Making it so.
Comment 21 Mike Beltzner [:beltzner, not reading bugmail] 2010-01-26 10:20:05 PST
--> 1.9.1.8-fixed
Comment 22 Henrik Skupin (:whimboo) 2010-01-27 17:23:11 PST
This has not been fixed by the mentioned bugs for 3.5.8pre builds like Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.8pre) Gecko/20100127 Shiretoko/3.5.8pre (.NET CLR 3.5.30729) ID:20100127050511

After a couple of minutes Firefox is still crashing: bp-c75cf819-b9ab-4fa0-bc8e-db80b2100127
Comment 23 Jonas Sicking (:sicking) PTO Until July 5th 2010-01-27 17:50:53 PST
See comment 18. The heap corruption issue, which is what this bug was filed as, is no longer there.

We do still crash due to out-of-memory problems. But that's a separate issue (and a incredibly generic one, there are loads of ways to get firefox to use up all your memory). Feel free to file a separate bug on that.

Sorry to be strict, but it makes tracking issues much easier. Especially since this has a ZDI number attached to it.
Comment 24 Henrik Skupin (:whimboo) 2010-01-28 03:24:08 PST
Sorry Jonas, I have overseen that comment. So I have filed bug 542742 for the remaining OOM crash. I have run builds pre/post of the patch landing under WinGDB and see a clearly different stack. So I will call it verified fixed.

Given by the other bugs the lastest fix on 1.9.2 has been checked-in for 1.9.2final. Updating flags accordingly. Can we remove the blocking1.9.3? flag?
Comment 25 Daniel Veditz [:dveditz] 2010-02-23 14:45:47 PST
"FIXED" is better, we know exactly which patches in "depends on" bugs made this problem go away.

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