14

Reading papers written by teams looking for vulnerabilities using fuzzing, I notice that many people label a crash as a DoS vulnerability. While in other papers and researches, they go deeper after the crash and try to exploit it to get RCE.

My question is whether all memory related crashes can lead to RCE or there are some prerogatives, and they don't even try.

Improve this question

2 Answers 2

Reset to default
20

Many crashes aren't exploitable for anything except denial-of-service (DoS). The most common example would be a NULL pointer read; attempting to dereference a pointer to (or anywhere near) 0 will fail, and unless the exception/signal is caught will cause the program to crash. However, just because the program tries to read from zero when given invalid input doesn't mean that it'll do anything more exciting if given a different invalid input.

Determining the exploitability of a crash is tricky. There's a few heuristics you can use (writes are usually worse than reads, if the instruction pointer is pointing at non-executable code - a NX/DEP violation - that's almost certainly exploitable, if it's a null pointer read then that's pretty unlikely to be exploitable) but they're not perfectly accurate. There are tools that will analyze a crash dump and try to guess for you (for example, Microsoft published a "!exploitable" command for the Windows debugger windbg that will perform this analysis; there are similar tools for Linux debuggers). To know for sure, you need to analyze the program flow that caused the memory corruption and see how much influence you have over it, and whether you can make it do anything actually dangerous.

Improve this answer
2
  • 9
    Other examples of crashes that are generally not exploitable: uncaught math exceptions (e.g. divide by zero), assertion failures, uncaught language/runtime exceptions that aren't related to memory corruption, memory corruption where the data and write address aren't (sufficiently) controllable.
    – Polynomial
    Commented Jan 22, 2020 at 6:33
  • 1
    @Polynomial Yep. Although some kinds of math issues (like integer overflows) can be exploitable, and being able to write memory can sometimes be exploitable even if you have little or no control where, so long as you have knowledge of where or of what the memory will be used for.
    – CBHacking
    Commented Jan 22, 2020 at 18:12
6

Consider a segfault caused by trying to access memory location 0x0 (ie a null pointer de-reference).

Maybe one part of the code thought it was done with a variable and set the pointer to null, and maybe under normal operations it really is done with it, but fuzz testing found some edge-case where something tries to read that variable again after it was set to null.

That will certainly cause a crash, because your application is trying to read kernel memory, and the kernel gets angry about that, but won't allow you to do anything RCE-like.

Improve this answer
2
  • 8
    NULL isn't usually kernel memory, it's just unmapped.
    – Criticizing Israel not allowed
    Commented Jan 22, 2020 at 10:29
  • 1
    And in many cases the first few pages are explicitly unmapped or marked as guard pages in order to harden against kernel vulnerabilities.
    – Polynomial
    Commented Jan 29, 2020 at 0:31

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .