If I understand correctly the hearbleed vulnerability, only the heap of the OpenSSL process can be retrieved by an attacker (or part of depending on the memory allocation type that is used). Then, how comes the OpenSSL process keeps in memory what it has encrypted/decrypted previously ?

It seems obvious that given the sensitivity of the OpenSSL process, there should not be any data kept in memory for longer that what's strictly needed, something like a "need to know" principle to ensure that the impact is kept at a reasonable level if the process is compromised.

I understand this sensitive data has to be put in memory to be communicated to the above layer/service (e.g. http server in most cases), but once it has been transmited it should be immediately removed, right ?

  • No, this is a different question. The one you refer to does not explain why and how such a situation is possible, it only explains what the exploit is doing. I am looking for detailed explanation about heap-management, not for an xkcd comic.
    – ack__
    Apr 12, 2014 at 12:53
  • @ack__ I quite liked that comic!
    – KnightOfNi
    Apr 12, 2014 at 23:32
  • I like it too, but it doesn't explain why this situation is even possible on modern OSes, it only explains what this bug and exploit are doing.
    – ack__
    Apr 13, 2014 at 9:52

2 Answers 2


In C, when you are finished using memory on the heap, you free() it which makes it available for use elsewhere. free() doesn't clear/wipe the memory to all zeros, so the next caller who asks for that memory will get the memory with its sensitive contents still intact unless you explicitly zero it before calling free(). Programs also often implement their own buffer/memory structures (e.g. OpenSSL's BUF_MEM) which depending on their implementation may or may not zero-out memory after use.

You are correct that sensitive data should only live in memory for as long as a need to know exists. It is best practice to zero out sensitive memory in these cases.

I can't say for sure in the case of OpenSSL since I haven't had an in-depth look at the code, but it could have been reading from memory that was still required, or memory that was no longer required but not zero'd-out, or a combination of the two.

More reading:


The data they can recover will be data that has passed through openssls encryption/decryption and is therefore stored within the memory of openssl

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .