User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; ja; rv:1.8.0.4) Gecko/20060508 Firefox/1.5.0.4 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; ja; rv:1.8.0.4) Gecko/20060508 Firefox/1.5.0.4 Javascript code that outputs too many SCRIPT element using "document.write" causes crash. Reproducible: Always Steps to Reproduce: 1.Enable JavaScript 2.Display TestCase Actual Results: firefox crashes with Application Error. Expected Results: stop execution of script before crash Windows Application Popup said, Instaruction at "0x004c868a" referenced memory at "0x006e0069." The memory cannot be written. (Original message was written in Japanese) The address seems to be random.

reproducible at Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a1) Gecko/20060718 Minefield/3.0a1

Talkback id is 21112564.

This TestCase doesn't causes crash.

Before crash, I recieved following error message(popup and event log): Your system is low on virtual memory. To ensure that Windows runs properly, increase the size of your virtual memory paging file. For more information, see Help. (Original message is witten in Japanese)

(In reply to comment #2) > reproducible at > Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a1) Gecko/20060718 > Minefield/3.0a1 > Talkback id is 21112968

These are all infinite loops, and since these loops are adding copies of themselves to the document they eventually exhaust your machine's resources and crash. Would be nice if these triggered the "unresponsive script" dialog, though since it's really a series of separately compiled scripts maybe we need an "unresponsive parser" check for pages which never finish. The console (in a debug build) does spit out "line XXX, too much recursion" over and over, maybe that would be a place to kill it. We might be doing just that, but are swamped by the multitude of scripts.

Talkbac incident ID of another crash caused by firest testcase is 2110947. In crash report, crash occured in ntdll + 0x4aff8, My ntdll.dll is Ver.5.0.2195.7006 (Japanese) included in "Update Rollup 1 for Windows 2000 SP4" (KB891861).

I think this bug contains two problems. 1.No method exists to stop infinite loop on these bug. 2.Incomplete check of memory allocation failure or memory overflow with "Low Memory of Windows". Woulb be nice to use memory allocation aliure test tool like failmalloc. But it supports only glibc-based system. http://enbug.org/project.html

I tested Thunderbird 1.5.0.5 with HTML mail containing this test case. Result : Tb is safe at this bug. Because Tb's sandbox creates Runtime Error of JavaScript. And the error stops infinite loop.

I confirmed with 2007012204-trunk/WinXP.

There's probably not a reason to keep this security-sensitive, is there? This is just a variant on ways to bypass the unresponsive script dialog and chew up resources at the same time.

I think it is very difficult to execute arbitrary code via crafted HTML using this bug. Crash probably occures when memory allocation failed, but it is not controllable from HTML(script), because free system memory size depends on all running applications. So, this bug is allows attackers to cause ONLY a denial of service. If DoS should not be security-sensitive at here, there is no reason to keep this security-sensitive.

At Fx 2.0.0.3 this bug is still reproducible. TB30588295K nsScannerString::AppendBuffer [mozilla/parser/htmlparser/src/nsScannerString.cpp, line 355] nsScanner::Append [mozilla/parser/htmlparser/src/nsScanner.cpp, line 336] nsHTMLDocument::WriteCommon [mozilla/content/html/document/src/nsHTMLDocument.cpp, line 2338] nsHTMLDocument::ScriptWriteCommon [mozilla/content/html/document/src/nsHTMLDocument.cpp, line 2420] nsHTMLDocument::Write [mozilla/content/html/document/src/nsHTMLDocument.cpp, line 2447] XPCWrappedNative::CallMethod [mozilla/js/src/xpconnect/src/xpcwrappednative.cpp, line 2169] XPC_WN_CallMethod [mozilla/js/src/xpconnect/src/xpcwrappednativejsops.cpp, line 1455] And at this crash, EventLog of Windows is witten: Application Popup: firefox.exe - Application Error: Instaruction at "0x0050b9f6" referenced memory at "0x00000000." The memory cannot be written.

Does everyone agree that this bug report should be opened?

I think it should be. I see how the crash should happen (a null pointer dereference makes sense) but not how we get into that state.

Sorry, that wasn't clear. I think this is an unexploitable null pointer dereference.

(In reply to comment #18) > Sorry, that wasn't clear. I think this is an unexploitable null pointer > dereference. > Somtimes, this bug causes null pointer dereference, but, it can causes other crashes too. (See comment #0)

I think this bug is buffer overflow. Caused by missing "Out Of Memory" detection. At multi-task OS, I think this bug causes ONLY DoS (see comment #14). At single-task OS, I think this bug might be exploitable, because memory usage is controllable from script.

I propose to divide this bug. 1.There is no method to stop inifinite loop of document parse. (Generally,It is caused by SCRIPT element that adds copy of itself to document) --> This bug's target after divide. 2.Insufficient check of "Out of memory" at document.write() causes crash. --> Another bug.

(In reply to comment #16) > Does everyone agree that this bug report should be opened? > I agree. Because all elements of this bug seems to be aready opened by Bug 380223 and Bug 401814.

First testcase (Attachement 229790) is obsolete. Because If system has enough memory, it does not causes crash.

Crash reproduced with attachment 229790 [details] on Safari 3.1.1/WinXP.

After bug 430574 isfixed, but browser does not crash, but hangs.

still hanging on the testcase on latest 3.5.3 Builds on Mac/Linux etc

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.4) Gecko/20100413 Firefox/3.6.4 I tried all 3 test cases. Tests 1 and 3 hung. Test 2 showed "unresponsive script" warnings. Clicking on "stop script" and closing the tab worked. Just hangs and unresponsive scripts, no crashes. There's a bit of improvement :)