345161 - JavaScript code creating too many SCRIPT element causes hang

Status: RESOLVED WORKSFORME

(Core :: General, defect)

Description

[Masahiro YAMADA]

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.

Comment 1

[Masahiro YAMADA]

Attachment: TestCase

Comment 2

[Masahiro YAMADA]

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

Comment 3

[Masahiro YAMADA]

Talkback id is 21112564.

Comment 4

[Masahiro YAMADA]

Attachment: testcase without carsh

This TestCase doesn't causes crash.

Comment 5

[Masahiro YAMADA]

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)

Comment 6

[Masahiro YAMADA]

Attachment: Another testcase. Talkback Id = 21145286

Comment 7

[Masahiro YAMADA]

(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

Comment 8

[Daniel Veditz [:dveditz]]

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.

Comment 9

[Masahiro YAMADA]

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).

Comment 10

[Masahiro YAMADA]

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

Comment 11

[Masahiro YAMADA]

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.

Comment 12

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

I confirmed with 2007012204-trunk/WinXP.

Comment 13

[Daniel Veditz [:dveditz]]

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.

Comment 14

[Masahiro YAMADA]

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.

Comment 15

[Masahiro YAMADA]

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.

Comment 16

[:Gavin Sharp [email: [e-mail]]]

Does everyone agree that this bug report should be opened?

Comment 17

[Blake Kaplan (:mrbkap) (inactive)]

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.

Comment 18

[Blake Kaplan (:mrbkap) (inactive)]

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

Comment 19

[Masahiro YAMADA]

(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)

Comment 20

[Masahiro YAMADA]

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.

Comment 21

[Masahiro YAMADA]

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.

Comment 22

[Masahiro YAMADA]

(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.

Comment 23

[Masahiro YAMADA]

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

Comment 24

[Masahiro YAMADA]

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

Comment 25

[Masahiro YAMADA]

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

Comment 26

[Carsten Book [:Tomcat]]

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

Comment 27

[Carlos Alén Silva]

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 :)

Comment 28

[Negritas Sergiu, Desktop QA]

Hello! I am closing this issue with RESOLVED->WORKSFORME since there where no changes made and there is no recent crash signatures in the past 6 months.