crash with OOM, document.write, <marquee>




HTML: Parser
8 years ago
2 years ago


(Reporter: 599eme Man, Unassigned)


({crash, testcase})

Firefox Tracking Flags

(Not tracked)


(Whiteboard: [sg:dos])


(1 attachment)



8 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv: Gecko/20091201 Firefox/3.5.6 (.NET CLR 3.5.30729)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv: 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 ?
Would you mind attaching a full testcase as an attachment?

Comment 2

8 years ago
Created attachment 419887 [details]
Javascript code to run the bug.
Possible stack from a non-debug nightly build:

#0  0x018f9616 in gfxFont::Measure(gfxTextRun*, unsigned int, unsigned int, gfxFont::BoundingBoxType, gfxContext*, gfxFont::Spacing*) () from ./
#1  0x018f99f6 in gfxTextRun::AccumulateMetricsForRun(gfxFont*, unsigned int, unsigned int, gfxFont::BoundingBoxType, gfxContext*, gfxTextRun::PropertyProvider*, unsigned int, unsigned int, gfxFont::RunMetrics*) () from ./
#2  0x018f9cf5 in gfxTextRun::MeasureText(unsigned int, unsigned int, gfxFont::BoundingBoxType, gfxContext*, gfxTextRun::PropertyProvider*) () from ./
#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 ./

Comment 4

8 years ago
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.


8 years ago
Summary: Remote Crash with possibility of Memory Corruption (document.write loop with html) → Possible memory corruption with OOM, document.write, <marquee>

Comment 5

8 years ago
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

8 years ago
cf bug 441675 from security researcher "SkyLined".


8 years ago
Whiteboard: [sg:needinfo]
This has been publicly reported at


8 years ago
Group: core-security
Duplicate of this bug: 544964

Comment 9

8 years ago
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"...)
Ever confirmed: true
Keywords: crash, testcase
Summary: Possible memory corruption with OOM, document.write, <marquee> → crash with OOM, document.write, <marquee>
Whiteboard: [sg:needinfo] → [sg:dos]
Duplicate of this bug: 563260


8 years ago
Duplicate of this bug: 566785

Comment 13

8 years ago
599eme Man's exploit is similar with below 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.

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


8 years ago
Duplicate of this bug: 576854


6 years ago
Duplicate of this bug: 727916


4 years ago
Duplicate of this bug: 1038471
Duplicate of this bug: 939453
You need to log in before you can comment on or make changes to this bug.