Hacker News Reader

Comment by pacaro | Hacker News Reader

I think this misses the point. The unchecked copy won't just copy freed memory, but will rather snapshot up to 64k of the heap, by issuing multiple malicious heartbeat packets and varying their size an attacker can probably build a fairly comprehensive view of the heap.

it might be interesting to consider storing keys out of the heap

View on HN

Exactly, this fails to understand a fairly fundamental aspect of the attack: you can read past the end of the buffer. Looking at the OpenSSL code, it appears the size of the buffer you're reading from is 16KiB+a few hundred bytes. (I could be wrong - not 100% sure I've followed the code correctly - but it's not going to be larger than that for various reasons.) You can read up to 64KiB-1 bytes from it.

Stack is traditionally accessible too. So you mean global/static memory? What languages would let you edit that? Can you get a pointer to it in C and change things, or is it stored in protected memory blocks with the program text?

You seem to suggest that the snapshot of the heap gets not just freed sections of the heap but the whole heap? If so then my other idea is invalidated (allocate on the heap a chunk of memory large enough for the keys and never free it, just re-use it when needed).

While I was testing on a server and out of a few hundred dumps never got any two with any common byte strings of more than 4 bytes among them.

How this bug actually ends up dumping information really depends a lot on luck.

Reply on news.ycombinator.com