| View previous topic :: View next topic |
| Author |
Message |
Apheus
Guru
Joined: 12 Jul 2008
Posts: 422
|
 Posted: Fri Apr 11, 2014 1:21 pm Post subject: heartbleed and CONFIG_PAX_MEMORY_SANITIZE |
 |
|
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. |
|
| Back to top |
|
 |
eccerr0r
Watchman
Joined: 01 Jul 2004
Posts: 9890
Location: almost Mile High in the USA
|
| Posted: Fri Apr 11, 2014 2:40 pm Post subject: |
|
|
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...
_________________
Intel Core i7 2700K/Radeon R7 250/24GB DDR3/256GB SSD
What am I supposed watching? |
|
| Back to top |
|
|
TomWij
Retired Dev
Joined: 04 Jul 2012
Posts: 1553
|
| Posted: Fri Apr 11, 2014 3:01 pm Post subject: Re: heartbleed and CONFIG_PAX_MEMORY_SANITIZE |
|
|
| Apheus wrote: | | 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)
Last edited by TomWij on Fri Apr 11, 2014 3:15 pm; edited 9 times in total |
|
| Back to top |
|
|
sk3l
Tux's lil' helper
Joined: 14 Jul 2012
Posts: 78
Location: CT USA
|
| Posted: Fri Apr 11, 2014 3:02 pm Post subject: |
|
|
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 |
|
| Back to top |
|
|
Apheus
Guru
Joined: 12 Jul 2008
Posts: 422
|
| Posted: Sat Apr 12, 2014 5:34 pm Post subject: |
|
|
| Thanks all, also for the links. Interesting read. |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Networking & Security
