heartbleed and CONFIG_PAX_MEMORY_SANITIZE

[Apheus]

With all the media coverage of the heartbleed bug (which is memory reuse issue), I wonder if the pax kernel option "sanitize all freed memory" (CONFIG_PAX_MEMORY_SANITIZE) server-side would have prevented the data leak, because the additional data would simply consist of zero bits. However, openssl uses an own memory manager, so from the kernel's perspective, the memory in question could still be used... while openssl happily reuses it for the heartbeat response.

I do not own a server, I'm simply curious.

[eccerr0r]

It would depend on the bug. Sometimes the bug will point back to valid address space of the calling process and it couldn't tell if it was a legal or illegal access. Don't know. I haven't seen the exact problematic code yet to see exactly what can be exploited, but it sounds like the private key is the target data (versus passwords - but with the private key, passwords come easily). Being that the private key is not that many bytes and if the hole points back to valid memory space, it's not hard to extract it.

Don't know... I'm not a security expert...

[TomWij]

With all the media coverage of the heartbleed bug (which is memory reuse issue), I wonder if the pax kernel option "sanitize all freed memory" (CONFIG_PAX_MEMORY_SANITIZE) server-side would have prevented the data leak, because the additional data would simply consist of zero bits. However, openssl uses an own memory manager, so from the kernel's perspective, the memory in question could still be used... while openssl happily reuses it for the heartbeat response.

No, it would at best have reduced the data leak but not prevented it, for two reasons: The first (as sk3l point outs below) reason is that in the memory of the process that is read there also would be memory that is still in use; the second (less known about, but much more important) reason is that OpenSSL uses its own handmade memory allocator as a wrapper around malloc and free. That handmade memory allocator keeps a cache around before it becomes sanitized, which allows the freed memory to be read for a longer time. As a result of this wrapper OpenSSL doesn't crash when it should when exploiting Heartbleed, as the wrapper allows the freed memory that it has cached to be read; when it would've crashed, an earlier security audit or attack would have made this bug non exploitable as well as clearly visible months ago. For more insight on this second reason, see the links pointed to from this post.

(Edit: Added various details and readability improvements)

[sk3l]

I don't believe that would have saved us in this instance. Like eccerr0r said, the overflow could end up overlapping live address space. Not only were private keys vulnerable, but user authen information, and possibly worst of all session cookie IDs. If the attacker got hold of a session cookie ID, they could spoof a saved session and impersonate you without needing to actually log in.

Here is a nice discussion of the bug details and risk level.

The thing very few folks are talking about is, yes, the code was poorly written, but the protocol semantics are not well thought out. What possible good can come from a keep alive mechanism that allows the client to set what data is used to pass back & forth. The heartbeat payload should be arbitrary, static & small, which IIRC is how it's implemented in TCP/IP

[Apheus]

Thanks all, also for the links. Interesting read.