537620 - crash with OOM, document.write, <marquee>

Status: RESOLVED INCOMPLETE

(Core :: DOM: HTML Parser, defect)

Description

[599eme Man]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.1.6) Gecko/20091201 Firefox/3.5.6 (.NET CLR 3.5.30729)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.1.6) Gecko/20091201 Firefox/3.5.6 (.NET CLR 3.5.30729)

I've searched possibility to remote Crash with the last version of Mozilla Firefox and I found it. When I do it with a debugger I saw EBX and other pile are corrupt with a lot of ("A"=> example).

So it's a Remote Crash with (I think) Memory Corruption.

The script is a loop for (150 times) in javascript with document.write.

It works on Seamonkey too.

Reproducible: Always

Steps to Reproduce:
1. Code a while (150 times) in javascript
2. With buffer+=buffer (="A") and document.write(buffer+buffer);
3. Open it remotely.
Actual Results:  
A remotely Crash with EBX pile corrupt.


Possibilty Memory Corruption ?

Comment 1

[Reed Loden [:reed]]

Would you mind attaching a full testcase as an attachment?

Comment 2

[599eme Man]

Attachment: Javascript code to run the bug.

Comment 3

[Reed Loden [:reed]]

Possible stack from a non-debug nightly build:

#0  0x018f9616 in gfxFont::Measure(gfxTextRun*, unsigned int, unsigned int, gfxFont::BoundingBoxType, gfxContext*, gfxFont::Spacing*) () from ./libxul.so
#1  0x018f99f6 in gfxTextRun::AccumulateMetricsForRun(gfxFont*, unsigned int, unsigned int, gfxFont::BoundingBoxType, gfxContext*, gfxTextRun::PropertyProvider*, unsigned int, unsigned int, gfxFont::RunMetrics*) () from ./libxul.so
#2  0x018f9cf5 in gfxTextRun::MeasureText(unsigned int, unsigned int, gfxFont::BoundingBoxType, gfxContext*, gfxTextRun::PropertyProvider*) () from ./libxul.so
#3  0x018fa2b3 in gfxTextRun::BreakAndMeasureText(unsigned int, unsigned int, int, double, gfxTextRun::PropertyProvider*, int, double*, gfxFont::RunMetrics*, gfxFont::BoundingBoxType, gfxContext*, int*, unsigned int*, int, gfxBreakPriority*) () from ./libxul.so

Comment 4

[599eme Man]

So arbitrary code could be executed with this remote crash ?
If it could, i'll try to code a Proof of Concept and write it here, if you code it before post it here too.

/599eme Man.

Comment 5

[Jesse Ruderman]

This testcase is guaranteed to make Firefox run out of memory (OOM), slowly, so it will probably crash in a different way on each computer depending on which malloc/new call fails first :(

Can you attach some information that you got from the debugger in the case that looked like memory corruption?  A stack trace would be good.  If you can figure out how we got from OOM to memory corruption, that would be superawesome.

To be honest, we could test OOM situations better than we do.  For example, we could artificially make malloc fail once in a hundred million times, combined with running our automated regression tests or fuzzing.  But we know that so much of our OOM-handling code is wrong that we'd rather fix it all at once (bug 427099).

Comment 6

[Jesse Ruderman]

cf bug 441675 from security researcher "SkyLined".

Comment 7

[Reed Loden [:reed]]

This has been publicly reported at http://www.securityfocus.com/bid/38132.

Comment 9

[599eme Man]

Reed Loden, i've post it on some security board, and a stupid people steal it on a forum (I know which because i've put a space before the "DoS"...)

Comment 10

[Reed Loden [:reed]]

Mentioned on sla.ckers.org forum:
http://sla.ckers.org/forum/read.php?13,33597,33597

Comment 13

[geinblues]

599eme Man's exploit is similar with below CVE-2006-2723

CVE-2006-2723:
Unspecified versions of Mozilla Firefox allow remote attackers to cause a denial of service (crash) via a web page that contains a large number of nested marquee tags. NOTE: a followup post indicated that the initial report could not be verified. 

http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-2723

hmm.. cause securityfocus assigned this problem on bid list.
and cve-id doesn't assigned on it?!

Comment 18

[Andrei Purice]

Is this issue still reproducible or can it be closed?

Comment 19

[Andrei Purice]

Marking this as Resolved > Incomplete due to the lack of info.
If anyone is able to reproduce this issue re-open it or file a new bug.