3 ms·
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/othe
by 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 agoSo, 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 agoAwesome. Thankyou.