Would you mind attaching a full testcase as an attachment?
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
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.
Summary: Remote Crash with possibility of Memory Corruption (document.write loop with html) → Possible memory corruption with OOM, document.write, <marquee>
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).
cf bug 441675 from security researcher "SkyLined".
This has been publicly reported at http://www.securityfocus.com/bid/38132.
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"...)
Mentioned on sla.ckers.org forum: http://sla.ckers.org/forum/read.php?13,33597,33597
Status: UNCONFIRMED → NEW
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]
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?!
You need to log in before you can comment on or make changes to this bug.