My understanding is that ASLR randomly arranges the key data areas of a process, and so reading contiguously above a buffer as is done in heartbleed would not be enough to achieve the exploit.


ASLR randomizes the addresses of critical parts of the processes memory, i.e. stack, heap and where libraries are loaded in order to make it unpredictable where a specific piece of code or data structure is located. But this kind of knowledge is not needed in the first place to exploit Heartbleed.

The Heartbleed vulnerability relies on an out of bounds read within an already allocated buffer on the heap. It does not need the base address of the heap for this, all what it needs is that sensitive data are still located at the heap and that they are located behind some newly allocated buffer. An image taken from Inference of Memory Bounds: Preventing the Next Heartbleed visualizes the problem nicely:

Out of Bounds Read

Relating to this image: in case of Heartbleed the buffer allocated for the TLS heartbeat was the blue one. But since the claimed size given in the heartbeat request was larger than the actual size of the heartbeat request and the heartbeat response trusted this wrong size OpenSSL ended up not only to include the payload of the original heartbeat request (blue) but also the data behind it on the heap (red) and thus leaked the sensitive information. No knowledge of any actual address was required for this.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.