5 ms·
In this case it appears to be a Null pointer de-reference. That type of bug is almost never exploitable since it almost always just leads to the program immedia
by 0x53 6y ago
In this case it appears to be a Null pointer de-reference. That type of bug is almost never exploitable since it almost always just leads to the program immediately terminating. An exploitable bug is one that has some way for the attacker to pivot and use it to do something else. For instance, a buffer overflow might allow an attacker to write some data in memory that could change the execution flow of a program.
- goalieca 6y agoThis kind of bug is only exploitable in the sense that you can deny service.
- a1369209993 6y agoIt's exploitable (more or less, depending on details) if the attacker can convince the program to map memory at address zero. Linux and possibly others usually refuse that without root approval, but I don't know of any systems where it's actually officially impossible. That said, it is rather difficult to exploit in practice, since being able to map memory at address zero is practically a vulnerablity in its own right, and you'd need to chain through that to get anywhere.
- tptacek 6y agoIt's generally not exploitable if the crash is triggered by a read, not a write, and it's not clear from the advisory which it is; writes to NULL can be exploitable if NULL is mapped (which is a configuration issue more than a permissions issue; it is most frequently not) or, more commonly, if the write address includes an attacker-controlled offset (though it may be the case that we've stopped referring to those conditions as NULL-involved). The ability to map arbitrary memory is, of course, as you point out, a game-over vulnerability by itself.
- a1369209993 6y ago> > depending on details Including read vs write, and what the read is used for, yes.
- nitrogen 6y agoHave there been any examples of an exploitable crash handler? E.g. a process traps SIGSEGV to print a backtrace upon NULL dereference, and then that signal handler is itself somehow exploitable?
- SCHiM 6y agoNot sure on the Linux situation. But this is an established technique on Windows, where stack canaries can be bypassed by overwriting SEH chains (trap handlers) on 32bit windows processes. Which are, strangely enough, recorded as function pointers on the stack. https://www.corelan.be/index.php/2009/07/25/writing-buffer-overflow-exploits-a-quick-and-basic-tutorial-part-3-seh/ https://www.corelan.be/index.php/2009/07/25/writing-buffer-o...
- monocasa 6y agoI've seen some cute work with corrupt DWARF tables (DWARF is internally a Turing complete VM). That work was more focused on hiding computation from virus scanners (so an edited binary), but I wonder if that could be used towards what you're getting at via runtime corruption.