Closed
Bug 432728
Opened 17 years ago
Closed 15 years ago
Assorted crashes with DOM reference fuzzer
Categories
(Firefox :: Security, defect)
Tracking
()
RESOLVED
DUPLICATE
of bug 581539
People
(Reporter: lcamtuf, Unassigned)
References
(Blocks 1 open bug, )
Details
(Keywords: meta, sec-other, Whiteboard: [sg:nse meta])
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]
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.
Reporter | ||
Comment 2•17 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.
Reporter | ||
Comment 3•17 years ago
|
||
Even more specifically, the references obtained from / the functions called in <IFRAME>.contentDocument trigger the behavior.
Comment 4•17 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.
Updated•17 years ago
|
Whiteboard: [sg:nse meta]
Comment 5•17 years ago
|
||
Reporter | ||
Comment 6•17 years ago
|
||
Can you CC: me there? Can't open them otherwise.
Comment 7•17 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..
Reporter | ||
Comment 8•17 years ago
|
||
Ookie, no worries.
Reporter | ||
Comment 9•15 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.
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → DUPLICATE
Updated•9 years ago
|
Group: core-security → core-security-release
Updated•3 years ago
|
Group: core-security-release
You need to log in
before you can comment on or make changes to this bug.
Description
•