4 ms·

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

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!

hannob 6y ago
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.
- colejohnson66 6y ago
  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?
  - 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 ago
      This kind of bug is only exploitable in the sense that you can deny service.
    - a1369209993 6y ago
      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.
      - tptacek 6y ago
        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.
        a1369209993 6y ago
        > > depending on details Including read vs write, and what the read is used for, yes.
        nitrogen 6y ago
        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?
        SCHiM 6y ago

hannob 6y ago

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.

colejohnson66 6y ago
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?
- 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 ago
    This kind of bug is only exploitable in the sense that you can deny service.
  - a1369209993 6y ago
    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.
    - tptacek 6y ago
      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.
      - a1369209993 6y ago
        > > depending on details Including read vs write, and what the read is used for, yes.
      - nitrogen 6y ago
        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?
        SCHiM 6y ago