Michal Zalewski Reporter
	Description • 16 years ago

Hi,

I put together a quick fuzzer that attempts to create various interesting objects, brute-force some references, and then destroy the object in question and reuse these stale refs as much as possible.

This seems to trigger a number of NULL pointer crashes in Firefox, and also some exploitable memory corruption issues; for example, one of the crashes I noticed with 2.0 was a dereference of address 0x4f52525d, which happens to be a part of an in-memory string (I do not have a debug build handy, so sorry for being vague).

To repro, use the URL above. This is a snapshot of the fuzzer as of this report. I'm still working on the code to minimize the number of cases where the fuzzer clobbers own window, as to make it easier to run it in unattended mode; with this snapshot, you might have to endure some faults of this type.

[Amusingly enough, this also kills all the other competing browsers]

	Bernd
	Comment 1 • 16 years ago

yes, this crashes trunk as well, 

I believe it is the iframe test

it triggers first a couple (>20 )
###!!! ASSERTION: XPConnect is being called on a scope without a 'Components' pr
operty!: 'Error', file d:/moz_src/mozilla/js/src/xpconnect/src/xpcwrappednatives
cope.cpp, line 765

and then it soon dies..

[object HTMLCollection @ 0x7db6450 (native @ 0x7dbc1d0)]WARNING: NS_ENSURE_TRUE(
mDocShell) failed: file d:/moz_src/mozilla/dom/src/base/nsGlobalWindow.cpp, line
 4090
WARNING: NS_ENSURE_TRUE(mDocShell) failed: file d:/moz_src/mozilla/dom/src/base/
nsGlobalWindow.cpp, line 4090
WARNING: NS_ENSURE_TRUE(mDocShell) failed: file d:/moz_src/mozilla/dom/src/base/
nsGlobalWindow.cpp, line 4090
WARNING: NS_ENSURE_TRUE(mDocShell) failed: file d:/moz_src/mozilla/dom/src/base/
nsGlobalWindow.cpp, line 4090
WARNING: NS_ENSURE_TRUE(mDocShell) failed: file d:/moz_src/mozilla/dom/src/base/
nsGlobalWindow.cpp, line 4090
WARNING: NS_ENSURE_TRUE(mDocShell) failed: file d:/moz_src/mozilla/dom/src/base/
nsGlobalWindow.cpp, line 4090
###!!! ASSERTION: You can't dereference a NULL nsCOMPtr with operator->().: 'mRa
wPtr != 0', file d:\moz_src\mozilla\obj-i686-pc-mingw32\dist\include\xpcom\nsCOM
Ptr.h, line 868

>[Amusingly enough, this also kills all the other competing browsers]
I would be surprised if your fuzzer would aim for less.

	Michal Zalewski Reporter
	Comment 2 • 16 years ago

Yup, IFRAME seems to be the offender. The NULL ptr crash is not the only failure mode, I believe (or the failure mode is the same, but the address referenced is not guaranteed to be NULL). I have repeatedly seen crashes on user-controlled memory access, as well.

	Michal Zalewski Reporter
	Comment 3 • 16 years ago

Even more specifically, the references obtained from / the functions called in <IFRAME>.contentDocument trigger the behavior.

	Martijn Wargers (dead)
	Comment 4 • 16 years ago

I got these stacktraces:
http://crash-stats.mozilla.com/report/index/c825ec2b-2038-11dd-b50b-001cc45a2ce4
http://crash-stats.mozilla.com/report/index/6a84f51e-203a-11dd-b77f-001a4bd46e84

Minimized testcases for the crashes (and new bugs created for that) would be great.

	Martijn Wargers (dead)
	Comment 5 • 16 years ago

I filed bug 434035 for the first crash mentioned in comment 4 and bug 434037 for the second one.

	Michal Zalewski Reporter
	Comment 6 • 16 years ago

Can you CC: me there? Can't open them otherwise.

	chris hofmann
	Comment 7 • 16 years ago

Hi Michal,

paul nickerson has also been invovled in some fuzzer development work for us and is interested in being added to this bug.  would that be ok?   jesse and dveditz can help vouch..

	Michal Zalewski Reporter
	Comment 8 • 16 years ago

Ookie, no worries.

	Michal Zalewski Reporter
	Comment 9 • 14 years ago

Duping this against bug 581539, since the fuzzer in 581539 is a much improved variant of ref_fuzz, and there's nothing happening on this bug anyway.