4 ms·

From the very top of the original disclosure webpage: "What leaks in practice? We have tested some of our own services from attacker's perspective. We attacke

From the very top of the original disclosure webpage: "What leaks in practice? We have tested some of our own services from attacker's perspective. We attacked ourselves from outside, without leaving a trace. Without using any privileged information or credentials we were able steal from ourselves the secret keys used for our X.509 certificates, user names and passwords, instant messages, emails and business critical documents and communication." So they explicitly confirmed they were able to get private key information. I've seen similar confirmations on twitter. I think it would be extremely unwise to trust that your keys are safe based on assumptions about the malloc implementation. And no offense to the OP, but I think the standard for "don't worry" on this issue is far higher than this blog post.

Karellen 13y ago
On the other hand, it is likely that the discoverers of Heartbleed, during their testing, were changing their service configs and restarting the SSH/Apache/other daemons frequently in order to test as many configurations as possible. It's entirely possible then that the OP's assertion is mostly correct, and that your key is more likely to be leaked if the attack is one of the first few requests to the daemon after it is started and the heap has been barely touched, and is significantly less likely to be leaked if the daemon has been up for some days and served many requests and its heap is more fragmented. Though I'm skeptical of the final "not possible", and would personally downgrade that to - at most - "very unlikely". It'd be nice to see some kind of study into how frequently the private key data is recoverable from the attack, against how many "normal" requests preceded the attack request.
- makomk 13y ago
  So, I've managed to obtain private keys from a test copy of Apache on Linux - very unreliably but it works sometimes - and I can't actually seem to get it to work at all with a freshly-started Apache. As far as I can tell, there actually needs to be a certain amount of prior heap activity before the attack stands a chance of working. Whilst I haven't analyzed exactly what happens, this particular attack is intended to look for keys in the format OpenSSL uses to store them permanently in RAM.
  - Karellen 13y ago
    Awesome. Thankyou.

Karellen 13y ago

On the other hand, it is likely that the discoverers of Heartbleed, during their testing, were changing their service configs and restarting the SSH/Apache/other daemons frequently in order to test as many configurations as possible. It's entirely possible then that the OP's assertion is mostly correct, and that your key is more likely to be leaked if the attack is one of the first few requests to the daemon after it is started and the heap has been barely touched, and is significantly less likely to be leaked if the daemon has been up for some days and served many requests and its heap is more fragmented. Though I'm skeptical of the final "not possible", and would personally downgrade that to - at most - "very unlikely". It'd be nice to see some kind of study into how frequently the private key data is recoverable from the attack, against how many "normal" requests preceded the attack request.

makomk 13y ago
So, I've managed to obtain private keys from a test copy of Apache on Linux - very unreliably but it works sometimes - and I can't actually seem to get it to work at all with a freshly-started Apache. As far as I can tell, there actually needs to be a certain amount of prior heap activity before the attack stands a chance of working. Whilst I haven't analyzed exactly what happens, this particular attack is intended to look for keys in the format OpenSSL uses to store them permanently in RAM.
- Karellen 13y ago
  Awesome. Thankyou.