This is my first post so please take it easy on me, I'm still learning. I have a question regarding debugging firefox. I have loaded the symbols from the symbol server and have some debug output; however, I am not sure what I am looking at. I am curious if this code might lead to a possible exploit? I have read a little on the recent heap spray and buffer overflow exploits on firefox and was thinking this might be along those lines. Once again I am a newbie, so if you could point me in the right direction to research I would appreciate it. My code:

index.html
-------------------------------------------
<!DOCTYPE HTML>
<html>
<head>
<title>DOS</title>
</head>
<body>
<p><h1>Please Wait, while I CRASH your Browser; it should not take long :)...</h1>:</p><div id="result"></div>

Okay... so I compiled the source code for !exploitable "!exploitable (pronounced “bang exploitable”) is a Windows debugging extension (Windbg) that provides automated crash analysis and security risk assessment."(http://msecdbg.codeplex.com/) and put the msce.dll in the Windows Debugger winext sub-directory. After running my code WinDbg gave me the following output using !expolitable:

Well that's the key in bug finding, you've got to make it exploitable. If you can influence the value of ds:002b:00000006=???? to be a section of memory then it may be exploitable. Try using different values in the code and see how exploitable reacts. BTW I'm not saying I'm an expert I'm still learning in this area

Thanks for the reply. I will try to throw some different values in and see what happens. Sort of fuzzing the input passed in to my code I guess? Anyway, I appreciate your feedback and will try some different values in my code. I am far from an expert as well; this is my first attempt at debugging a crash.

If I change the index.html code to the following firefox does not crash right away but rather stalls and creates a memory leak.??? I am trying different inputs for my code and getting very different results and crashes depending on the input. If anyone is willing to try fuzzing input for the code and see what type of results they are getting in FF3.5 I would appreciate it. I am just curious if different results/crashes might be found and how varied those results might be. Thanks for the help and feedback.

One interesting part which I noticed is the access violation occurs at the same address location which is stored in the eip register. I am still new to this debugging of a crash; however, I am willing to learn.

Okay... so after a little testing on my own I decided to turn to Mozilla to see if they might have any ideas. After a week I got the following email from them:

"I poked at this a bit and I don't like it. Based your output it looks relatively benign, a near-null read and probable resource exhaustion (based on the testcase).

I crashed in a few different spots, still "near null", but sometimes during garbage collection, and a few times the "near null" was due to an integer overflow of adding 8 to a register containing 0xffffffff.
crashing during garbage collection is usually a very bad sign. Although I didn't find any simple modifications that moved the crash around but I can't rule out the possibility of this being exploitable.

I filed bug https://bugzilla.mozilla.org/show_bug.cgi?id=514554 and can give you access if you have a bugzilla account."

So a bug has been filed under bugzilla and I am left with the same question... Exploitable or Not? Once again if anyone has any ideas, or can point me in another direction to research I would appreciate it.

Yes... Yes, I have a new PoC which seems to work from my limited testing. I believe it may be some kind of race condition within the javascript web worker. Either way, part of the time it crashes on the bug which I made mozilla aware of, the other part of the time it chrashes in an access violation error:

User mode write access violations that are near NULL are probably exploitable.

The code is a mess right now... I have been fuzzing it with diffrent input. Give it a go and let me know if it crashes your FF3.5 browser. If you have any time to debug the crash please post some output.

You might have to run the code a few times to get it to crash on a diffrent place then the xul!XPCNativeSet::Mark: error. Like I said I have not had to much time to work on the code, it is mostly a jumbled mess right now. I still am trying to find out how I can overwrite the registers.

Like I said... the program should crash your browser; however, try it several times as it will crash on diffrent errors. Part of the time it should display that Firefox was closed by DEP, which is most likly a very bad thing.

Okay... so the http://www.mozilla.org/security/announce/2009/mfsa2009-54.html bug/exploit which I reported was "Fixed" in the new version http://news.cnet.com/8301-30685_3-10385082-264.html FF3.5.4... or was it? Check out my http://cybermediaplanet.com/security.html PoC and at http://wiki.austinhackers.org/2009-09-30-0x0024 AHA.