

Understanding the Heartbleed Proof of Concept - richm44
http://www.westpoint.ltd.uk/blog/2014/04/14/understanding-the-heartbleed-proof-of-concept/

======
ithkuil
> If we get a response that's longer than the 3 bytes of data we actually sent
> (as opposed to the 16384 bytes we claimed we sent) then the server is
> vulnerable and the extra data sent back is part of the contents of the
> memory of the server.

Not necessarily. The server could run a custom patch that fills the buffer
with /dev/urandom. You might still find user secrets in that buffer as well as
a full Shakespeare work if you try hard enough.

That said, I don't see why one would do that, except perhaps to waste
attackers resources trying to check all the returned garbage for potential
private keys.

~~~
schwap
Additionally, even if you send a heartbeat message with the correct length
(3), you will ALWAYS get > 3 bytes because OpenSSL pads the response with 16
bytes of random data.

~~~
richm44
Sure, I simplified things a little bit for clarity. The aim was really to get
away from people just looking at the block of hex and seeing 'magic'. :-)

------
moyix
One important thing to realize about the PoC -- if you change "40 00" to "FF
FF" or similar, it may seem that you still only get 16KB back. In fact (in
violation of the TLS spec) OpenSSL is just fragmenting heartbeat message into
multiple packets. If you modify the script to read and print heartbeat
responses in a loop, you can get the full 64KB mentioned in the advisory.

~~~
richm44
That's a very good point (and easy to change in the code). When I was thinking
about what to write I considered making a modified version of the PoC that was
a bit more readable and adding a few tweaks like handling different TLS
versions but in the end I decided that explaining it as-is would be worthwhile
in itself.

