Hacker News Reader

Comment by zschuessler | Hacker News Reader

Does anyone know how easy it is to execute this attack? I realize it's high severity, but can't accurately say if I should drop everything I'm doing and upgrade all servers, or wait until this evening..

Seems like the most likely attack vector is having a server check a malicious certificate, which happens automatically in some cases. But not always. And it's unclear what prompts the automatic check in the first place - perhaps the server executing a remote HTTPS request a malicious user specifies?

Thanks in advance!

View on HN

It's a crash only. So it's not gonna compromise your machine, worst case is something not running any more.

The conditions are also rather special, it seems the most likely scenario is that you have any software that verifies certificates and automatically checks CRLs and there's a way for an attacker to provide you a bad certificate and a CRL. That's not something that I'd expect to be very common.

As someone who doesn’t dig much into security fixes, when does a simple crash become exploitable? Because my understanding is that a crash is an indication that something could be exploitable, so how de we know this one isn’t?

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.

This kind of bug is only exploitable in the sense that you can deny service.

It'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.

It'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.

> > depending on details

Including read vs write, and what the read is used for, yes.

Have 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?

Not 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-o...

I'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.

Reply on news.ycombinator.com