It's not all that he's reporting, he's just assuming some hacking knowledge I guess. Every time you see a crash which is caused by jumping to some unknown address, there's a pretty good chance that the crash is exploitable - but you can't tell that easily without going through the source / poking around the binary.
Basically in many cases the jumps into non-code areas mean that some buffer overflowed (or some pointer got corrupted) and overwrote the stack frame return address. As long as you can control what was overwritten, you're likely to be able to point at the data you supplied yourself (back at the stack with some text you control). If that condition is true, you can provide new code for execution straight from html - that means the crash is exploitable.
Then again, even if you can't see how is that specific crash exploitable, it doesn't mean it isn't. For some time double-free crashes were just bugs. Then someone found out you can manipulate the pointers in possible later reallocations. What I'm trying to say is that every crash caused by user supplied data should be looked at from the "might be exploitable in the future" perspective.
> Every time you see a crash which is caused by jumping to some unknown address, there's a pretty good chance that the crash is exploitable
No. It's not 2001. Modern MS (and UNIX) operating systems and compilers use NX, stack guarding, and addr randomization to make stack/heap overflows pretty difficult to exploit. Not impossible, but statistically unlikely. Run-of-the-mill C programming errors in a web browser are hardly automatic remote sploits now.
> every crash caused by user supplied data should be looked at from the "might be exploitable in the future" perspective.
OK, I agree with this, but out of principle, not because there's a high chance it's remotely exploitable.
Basically in many cases the jumps into non-code areas mean that some buffer overflowed (or some pointer got corrupted) and overwrote the stack frame return address. As long as you can control what was overwritten, you're likely to be able to point at the data you supplied yourself (back at the stack with some text you control). If that condition is true, you can provide new code for execution straight from html - that means the crash is exploitable.
Then again, even if you can't see how is that specific crash exploitable, it doesn't mean it isn't. For some time double-free crashes were just bugs. Then someone found out you can manipulate the pointers in possible later reallocations. What I'm trying to say is that every crash caused by user supplied data should be looked at from the "might be exploitable in the future" perspective.