4 ms·

Heartbleed I just about understand, as despite this not being my field, smart people successfully summarized it in an easily digestible way so that I could even

by Nexxxeh 13y ago

Heartbleed I just about understand, as despite this not being my field, smart people successfully summarized it in an easily digestible way so that I could even explain it to my mum. Can someone ELI5 this too please?

deadfa11 13y ago
Basically, measure the time difference in the memory comparison. Typically, comparisons will short-circuit. That is, stop as soon as a difference is detected. But this is a problem for security situations like key comparisons. If 10 out of 20 bytes match, it will take a little bit longer to compare then if 5 out of 20 bytes match. With enough iterations, the key can be recovered due to these differences in time. The correct solution is to use a constant time comparison that always runs through the entire sequence of bytes.
Rygu 13y ago
See that the memcmp() comparison takes longer as you guess the next byte correctly. Repeat until all bytes known.
Moral_ 13y ago
memcmp does a binary level comparison of data. On many versions, memcmp will return exactly when it sees a difference between the two buffers. Because it returns immediately one can figure out what byte it failed at due to timing and construct the correct input. Some others have pointed out that it's a static function, which I stupidly overlooked. Others have pointed out it's not really used anymore so the title doesn't accurately reflect the issue. -- I will probably delete this thread.
- pipeep 13y ago
  It wasn't static for older versions of OpenSSL, so this still might be an issue if someone was using that function with the assumption of it being constant-time.
pipeep 13y ago
memcmp compares two blocks of memory byte-by-byte. If the first two bytes don't match, the function can return early, otherwise it has to check the next byte. By measuring the execution times for all 256 possible bytes, one should be able to guess the first byte. Repeat this for the length of the memory being compared, and you should be able to essentially read the entire block of memory you're being compared against. These attacks are usually done over a fast connection (maybe buy a machine in the same datacenter as your target), and through lots of measurements averaged together and measured for statistical significance. We don't know where this function is used, so this might actually be a non-issue. We need someone more familiar with OpenSSL to comment.
- solarexplorer 13y ago
  What kind of connection is fast enough to detect the difference of a single loop iteration inside memcmp()? I get that this is type of attack is possible if you share the same machine with the attacker. But over the network? Are there any credible sources for this?
  - deleted 13y ago
    [deleted]
  - gsnedders 13y ago
    You don't need fast — you need predictable latency, that's all. Once you have predictable latency, you can work out compute time. And latency can become predictable through a large number of samples. Brumley and Boneh's 2003 paper ("Remote timing attacks are practical") on this is the typical reference: http://crypto.stanford.edu/~dabo/papers/ssl-timing.pdf http://crypto.stanford.edu/~dabo/papers/ssl-timing.pdf
    - solarexplorer 13y ago
      My point is that to receive a single packet, you have an external interrupt, you go through the device driver, the ip stack, etc. And in all that you are looking for a difference of a single cycle. That won't work. Even with a zero latency network. There is just too much code involved. You can measure differences of thousands or maybe even hundreds of cycles, but not single cycles. That's below the noise level of a modern computer.

by Nexxxeh 13y ago

deadfa11 13y ago

Basically, measure the time difference in the memory comparison. Typically, comparisons will short-circuit. That is, stop as soon as a difference is detected. But this is a problem for security situations like key comparisons. If 10 out of 20 bytes match, it will take a little bit longer to compare then if 5 out of 20 bytes match. With enough iterations, the key can be recovered due to these differences in time. The correct solution is to use a constant time comparison that always runs through the entire sequence of bytes.

Rygu 13y ago

See that the memcmp() comparison takes longer as you guess the next byte correctly. Repeat until all bytes known.

Moral_ 13y ago

memcmp does a binary level comparison of data. On many versions, memcmp will return exactly when it sees a difference between the two buffers. Because it returns immediately one can figure out what byte it failed at due to timing and construct the correct input. Some others have pointed out that it's a static function, which I stupidly overlooked. Others have pointed out it's not really used anymore so the title doesn't accurately reflect the issue. -- I will probably delete this thread.

pipeep 13y ago
It wasn't static for older versions of OpenSSL, so this still might be an issue if someone was using that function with the assumption of it being constant-time.

pipeep 13y ago

memcmp compares two blocks of memory byte-by-byte. If the first two bytes don't match, the function can return early, otherwise it has to check the next byte. By measuring the execution times for all 256 possible bytes, one should be able to guess the first byte. Repeat this for the length of the memory being compared, and you should be able to essentially read the entire block of memory you're being compared against. These attacks are usually done over a fast connection (maybe buy a machine in the same datacenter as your target), and through lots of measurements averaged together and measured for statistical significance. We don't know where this function is used, so this might actually be a non-issue. We need someone more familiar with OpenSSL to comment.

solarexplorer 13y ago
What kind of connection is fast enough to detect the difference of a single loop iteration inside memcmp()? I get that this is type of attack is possible if you share the same machine with the attacker. But over the network? Are there any credible sources for this?
- deleted 13y ago
  [deleted]
- gsnedders 13y ago
  You don't need fast — you need predictable latency, that's all. Once you have predictable latency, you can work out compute time. And latency can become predictable through a large number of samples. Brumley and Boneh's 2003 paper ("Remote timing attacks are practical") on this is the typical reference: http://crypto.stanford.edu/~dabo/papers/ssl-timing.pdf http://crypto.stanford.edu/~dabo/papers/ssl-timing.pdf
  - solarexplorer 13y ago
    My point is that to receive a single packet, you have an external interrupt, you go through the device driver, the ip stack, etc. And in all that you are looking for a difference of a single cycle. That won't work. Even with a zero latency network. There is just too much code involved. You can measure differences of thousands or maybe even hundreds of cycles, but not single cycles. That's below the noise level of a modern computer.