441670 - Lots of document.write()s with large strings triggers Access Violation

Status: RESOLVED DUPLICATE of bug 430574

(Core :: General, defect)

Description

[u315569]

User-Agent:       Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; WOW64; SLCC1; .NET CLR 2.0.50727; .NET CLR 3.0.04506; .NET CLR 1.1.4322)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.8.1.14) Gecko/20080404 Firefox/2.0.0.14

This appears to be some race condition, as the script can run for varying amounts of time before it crashes FireFox. It often seems to crash with a NULL pointer in an AddRef call, which leads me to believe it is reuse of freed memory or use of uninitialised memory in some COM object. I have seen crashes at random addresses, so I think it may be exploitable.

The code:
<SCRIPT language="JavaScript">
	var sChunk = "A";
	while (sChunk.length < 0x10000) {
		sChunk += sChunk;
	}
	var sString = sChunk;
	for (var i = 0; i < 3000; i++) {
		sString += sChunk;
		document.title = i+"|" + sString.length.toString(16);
		document.write(sString);
	}
</SCRIPT>

Reproducible: Sometimes

Steps to Reproduce:
Load this URL:
* http://skypher.com/SkyLined/Repro/FireFox/AccessViolation%209e7d9165.html
Actual Results:  
FireFox crashes after a while, the time required to crash it varies. For me it normally requires 10-20 seconds.

Expected Results:  
FireFox crashes

I reported this problem on May 20, 2008 to [e-mail] in an email with the title "Exploitable memory corruption when writing a lot of data to a page from JavaScript" but have not received a reply, which is why I'm filing this bug.

Comment 1

[Brandon Sterne (:bsterne)]

I tested both the URL you provided as well as the sample code from a local web server on both Trunk and Firefox 2.0.0.14.  In every case, my browser hung, but I never crashed.  I left the test cases running for 4-5 minutes before Force Quitting.

Is anyone else able to reproduce the crash?

Comment 2

[Lucas Adamski [:ladamski]]

I got it to crash (3.0.1 / OS X 10.5) eventually, it just took a while.  Exploit appears to require a fair amount of memory.

Comment 3

[Samuel Sidler (old account; do not CC)]

Lucas, can you attach a crash log or link to a breakpad report?

Comment 4

[Lucas Adamski [:ladamski]]

Here you go:
bp-ec2504ba-8e60-11dd-8d11-001cc45a2ce4
and bp-4e81c866-8c1b-11dd-9f60-001cc45a2ce4

Comment 5

[Daniel Veditz [:dveditz]]

crash in nsScannerString::AppendBuffer, a duplicate of bug 401814? (null deref after OOM).

Anyone get crashes with other stacks?

Comment 6

[Johnny Stenback (:jst)]

This doesn't seem to be Windows specific as both crash reports linked above are from Mac's. Reassigning to bnewman. Looks like this could indeed be a dupe of bug 401814, in which case this is likely not a high severity security bug.

Comment 7

[Boris Zbarsky [:bzbarsky]]

So... I can't get trunk to crash (will try 1.8 and 1.9 later, I guess), but I do get a whole bunch of failed mmaps on trunk.

Comment 8

[Ben Newman (:bnewman) (:benjamn)]

(In reply to comment #7)
> So... I can't get trunk to crash (will try 1.8 and 1.9 later, I guess), but I
> do get a whole bunch of failed mmaps on trunk.

That's what I'm seeing in trunk, too.  CVS HEAD crashes after a minute or two on my mac, in nsScannerString::AppendBuffer.  Does look very much like bug 401814 (which still needs fixing).

Comment 9

[Boris Zbarsky [:bzbarsky]]

Ah, indeed.  I'll comment in that bug.

Comment 10

[Boris Zbarsky [:bzbarsky]]

So I can confirm that the patch from bug 430574 applies cleanly on 1.9.0 and fixes this bug.

Comment 11

[Johnny Stenback (:jst)]

So this should be marked fixed then now, right?

Comment 12

[Boris Zbarsky [:bzbarsky]]

Ah, yeah.