This article will help you determine if a crash is exploitable, find crashes which are exploitable, and to fix exploitable crashes.
What is an exploitable crash?
A crash report from your debugger, your OS, or Mozilla crash-stats can tell you a lot about whether or not a crash is potentially exploitable. You want to look primarily for three things, in order:
- Look at the top frame of the stack trace. If you see a hex address such as 0x292c2830 rather than a function name such as nsListBoxBodyFrame::GetRowCount at the top of the stack, a bug has caused the program to transfer control to a "random" part of memory that isn't part of the program. These crashes are almost always exploitable to run arbitrary code.
- Look at the crash reason, which will usually be something like "KERN_PROTECTION_FAILURE (0x0002) at 0x00000000". This is typically located right above the stack trace. The last number, in this case 0x00000000, is the memory address Firefox was prevented from accessing. If the address is always zero (or close to zero, such as 0x0000001c), it's probably a null dereference bug. These bugs cause the browser to crash, but they do so in a predictable way, so they are not exploitable. Most crashes fall into this category.
- Check the length of the stack trace. If it's over 300 functions long, it's likely to be a too-much-recursion crash. Like null dereferences, these crashes are not exploitable.
Any other crash where Firefox tries to use memory it does not have access to indicates some kind of memory safety bug. These crashes can often be exploited to run arbitrary code, but you can't be as certain as in the case where you see a bogus address at the top of the stack in step 1.
Finding exploitable crashes
Exploitable crashes are most often discovered through normal testing and usage, when developers recognize a crash stack in gdb or submitted to a bug as exploitable.
Additionally, Mozilla developers make heavy use of two tools in particular to find exploitable situations before they show up as exploitable crash reports.
The first tool is AddressSanitizer (ASAN). There is an MDN article documenting its use with Mozilla projects.
The other tool is Valgrind. There is an MDN article documenting its use with Mozilla projects.
Next steps
Once you've determined that a crash is potentially exploitable, take the following steps. If you need help with any of the steps (e.g. perhaps you lack necessary bugzilla privileges) please email [email protected].
- Make sure a bug is on file.
- Mark the bug as security-sensitive by putting it into the "Security-Sensitive Core Bug" group. Do this before making comments or taking actions that expose exploitability publicly.
- Put a security severity rating in the bug's keywords. If you're not sure what rating to give, err on the higher side so the bug will get more attention.
- Explain in a comment why the issue seems exploitable.
Other tools
Apple has a tool called "crashwrangler" that are still being maintained as of 2012. There is little public information about it, and it is hard to find even on the Apple developer site. To get them go to the Mac Developer Center downloads section -> Other Downloads -> search for "crashwrangler".
Microsoft released a debugger extension tool in 2009 called "!exploitable". It hasn't been updated since 2009.
See also
- Jesse Ruderman's 2006 blog post on exploitability. This post provided much material for this article.