Note: There are a few cases of duplicates in user autocompletion which are being worked on.
Bug 533000 (CVE-2010-0160)

Web Worker Array Handling Heap Corruption Vulnerability (ZDI-CAN-624)

RESOLVED FIXED in mozilla1.9.2

Status

()

Core
DOM
--
critical
RESOLVED FIXED
8 years ago
7 years ago

People

(Reporter: dveditz, Unassigned)

Tracking

({crash, verified1.9.1})

Trunk
mozilla1.9.2
x86
Windows Vista
crash, verified1.9.1
Points:
---
Dependency tree / graph
Bug Flags:
blocking1.9.2 -
wanted1.9.0.x -

Firefox Tracking Flags

(blocking2.0 final+, status1.9.2 final-fixed, blocking1.9.1 .8+, status1.9.1 .8-fixed)

Details

(Whiteboard: [sg:critical?] See comment 18, remaining OOM DoS moved to bug 542742)

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
blocking1.9.1: --- → ?
blocking2.0: --- → ?
Flags: wanted1.9.0.x?
Flags: blocking1.9.2?
Flags: blocking1.9.0.17?
I've asked for a copy of the "workCRASH1.js" script
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.
We don't have workers on 1.9.0, so this shouldn't block there.
Flags: wanted1.9.0.x?
Flags: wanted1.9.0.x-
Flags: blocking1.9.0.17?
(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?
Flags: wanted1.9.0.x?
Flags: wanted1.9.0.x-
Flags: blocking1.9.0.17?
(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.
Thanks, Reed, for setting all the blocking flags. Since we can't reproduce this at the moment, not blocking 1.9.2.
Flags: blocking1.9.2? → blocking1.9.2-
(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.
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.
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
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.
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.
Ben: does this also crash in 3.6 and trunk, or was it fixed in those versions?
blocking1.9.1: ? → .7+
status1.9.1: --- → wanted
Flags: wanted1.9.0.x?
Flags: wanted1.9.0.x+
Flags: blocking1.9.0.17?
Flags: blocking1.9.0.17+
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.
Flags: wanted1.9.0.x?
Flags: wanted1.9.0.x+
Flags: blocking1.9.0.17?
Flags: blocking1.9.0.17+
Created attachment 417764 [details]
PoC files
(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.
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.
Flags: wanted1.9.0.x?
Flags: wanted1.9.0.x-
Flags: blocking1.9.0.18?
Whiteboard: [sg:critical?] → [sg:critical?][fixed by bug 502687]
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?
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.
WONTFIX based on that.
Status: NEW → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → WONTFIX
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.
Resolution: WONTFIX → WORKSFORME
--> 1.9.1.8-fixed
status1.9.1: wanted → .8-fixed
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
Status: RESOLVED → REOPENED
status1.9.1: .8-fixed → ?
Resolution: WORKSFORME → ---
Whiteboard: [sg:critical?][fixed by bug 502687] → [sg:critical?]
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.
Status: REOPENED → RESOLVED
Last Resolved: 8 years ago8 years ago
Resolution: --- → WORKSFORME
Whiteboard: [sg:critical?] → [sg:critical?] See comment 18. Still crashes, but that's a separate, non exploitable, issue.
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?
status1.9.1: ? → .8-fixed
status1.9.2: --- → final-fixed
Keywords: verified1.9.1
Target Milestone: --- → mozilla1.9.2
Depends on: 534051
Depends on: 531222
Alias: CVE-2010-0160
"FIXED" is better, we know exactly which patches in "depends on" bugs made this problem go away.
Resolution: WORKSFORME → FIXED
Whiteboard: [sg:critical?] See comment 18. Still crashes, but that's a separate, non exploitable, issue. → [sg:critical?] See comment 18, remaining OOM DoS moved to bug 542742

Updated

7 years ago
Depends on: 560144

Updated

7 years ago
No longer depends on: 560144
Group: core-security
blocking2.0: ? → final+
You need to log in before you can comment on or make changes to this bug.