609358 - (document-write-dos) Denial-of-service crashes from long strings and document.write

Status: RESOLVED WONTFIX

(Core :: General, defect)

Description

[Brandon Sterne (:bsterne)]

A common pattern: pass a long string to document.write inside a loop

var s = "A";
for (var i = 0 ; i < 0xfffffffff ; i++) {
  s = s + s;
  document.write(s);
}

will trigger out-of-memory aborts or null dereference crashes downstream from layout object creation failures such as this one on Linux:

Program received signal SIGSEGV, Segmentation fault.
0x008c11df in gfxTextRun::IsClusterStart (this=0x0, aPos=0) at ../../dist/include/gfxFont.h:1331
1331	        NS_ASSERTION(0 <= aPos && aPos < mCharacterCount, "aPos out of range");
(gdb) bt
#0  0x008c11df in gfxTextRun::IsClusterStart (this=0x0, aPos=0) at ../../dist/include/gfxFont.h:1331
#1  0x01c34189 in TextRunWordCache::FinishTextRun (this=0xb47f9d30, aTextRun=0xab61b9a0, aNewRun=0x0, 
    aParams=0xbfff9478, aDeferredWords=..., aSuccessful=0)
    at /build/m-c/mozilla/gfx/thebes/gfxTextRunWordCache.cpp:456
#2  0x01c35d11 in TextRunWordCache::MakeTextRun (this=0xb47f9d30, 
    aText=0xa1100008 'A' <repeats 200 times>..., aLength=134217727, aFontGroup=0xab7a5bc0, 
    aParams=0xbfff9478, aFlags=22282528) at /build/m-c/mozilla/gfx/thebes/gfxTextRunWordCache.cpp:819
#3  0x01c36650 in gfxTextRunWordCache::MakeTextRun (aText=0xa1100008 'A' <repeats 200 times>..., 
    aLength=134217727, aFontGroup=0xab7a5bc0, aParams=0xbfff9478, aFlags=22282528)
    at /build/m-c/mozilla/gfx/thebes/gfxTextRunWordCache.cpp:1013
#4  0x008acdbf in MakeTextRun (aText=0xa1100008 'A' <repeats 200 times>..., aLength=134217727, 
    aFontGroup=0xab7a5bc0, aParams=0xbfff9478, aFlags=22282528)
    at /build/m-c/mozilla/layout/generic/nsTextFrameThebes.cpp:531
#5  0x008b07f1 in BuildTextRunsScanner::BuildTextRunForFrames (this=0xbfffb99c, aTextBuffer=0xa9100007)
    at /build/m-c/mozilla/layout/generic/nsTextFrameThebes.cpp:1880


This ticket can be used as a catch-all for the inevitable numerous permutations of this bug that are submitted.

Comment 2

[Jonathan Kew [:jfkthame]]

Attachment: patch, check for null return from gfxFontGroup::MakeTextRun

In general, dumping huge strings into the document should eventually lead to an out-of-memory abort. However, this crash shows a case where we allow an allocation to fail (without aborting) but then don't handle the failure properly, hence the null-deref.

When TextRunWordCache::MakeTextRun creates a new run, it's possible that gfxFontGroup::MakeTextRun will return NULL (if it failed to allocate memory for the glyphs and text). This will lead to aSuccessful==FALSE in FinishTextRun(), and in this case we must avoid dereferencing the "source" run pointer within the FinishTextRun loop, as it may be null.

Comment 3

[Brandon Sterne (:bsterne)]

I do appreciate the patch and the bug metadata cleanup, but really I filed this ticket as a meta bug to dupe all the dozens of permutations of this pattern that we've seen lately (see comment 0).  Johnathan just happened to debug the crash stack for one particular instance and attached a patch.  I'd prefer to keep this bug meta and file individual crash bugs that block this one.

I'll file the bug that timeless wanted to morph this one to and make it block this bug, and maybe Johnathan can move the patch there.

Comment 4

[Karl Tomlinson (:karlt)]

Comment on attachment 488204 [details] [diff] [review]
patch, check for null return from gfxFontGroup::MakeTextRun

Moved to bug 609691.

Comment 9

[Andrei Purice]

Closing this as Resolved > Incomplete since the reporter cannot be contacted to confirm its repro or current state.

Comment 10

[Andrew McCreight [:mccr8]]

This is still an issue, but I don't know if this bug needs to stay open. I think the history here is that there was some exploit that doubled strings around 2009, and it got added to some compilation of exploits. Periodically, intrepid security researchers go through and run these ancient exploits to see what happens, and when this one crashes they assume that the exploit must be valid, so they file a bug. In actuality, it is now simply a safe memory exhaustion crash, so we don't really care. I think this bug was intended to be a dumping ground for dupes when they were inevitably filed.