So one of the side-discussions happening after Heartbleed was the fact that OpenSSL has its own memory allocator code that effectively mitigates any C library-provided exploit mitigations (as discussed on the openbsd-misc ML at [1] and Ted Unangst's blogs at [2] and [3]). This is partially why there's so much "interesting" data to be sniffed from a server's memory via the heartbleed response packets -- that memory wasn't really initialized to random data or zero'd upon malloc(), nor garbage-collected upon free().
Taking place over on the openssl-users ML, someone from Akamai posted a new secure memory allocator patch[4][5] that they have been using in production for about a decade. That patch was cleaned up, diff'ed against openssl-1.0.1g, and posted to openssl-dev here: https://marc.info/?l=openssl-dev&m=139733477712798&q=p5 It basically provides a secure memory area protected by guard pages for sensitive data, like RSA private keys, so that if another Heartbleed-like event occurs, things won't be as bad. Hopefully... Is this something we want to look at adding to our openssl copy via an optional USE flag (default off)? Refs: 1. http://marc.info/?l=openbsd-misc&m=139698608410938&w=2 2. http://www.tedunangst.com/flak/post/heartbleed-vs-mallocconf 3. http://www.tedunangst.com/flak/post/analysis-of-openssl-freelist-reuse 4. http://marc.info/?l=openssl-users&m=139723710923076&w=2 5. http://marc.info/?l=openssl-users&m=139723972124003&w=2 -- Joshua Kinard Gentoo/MIPS ku...@gentoo.org 4096R/D25D95E3 2011-03-28 "The past tempts us, the present confuses us, the future frightens us. And our lives slip away, moment by moment, lost in that vast, terrible in-between." --Emperor Turhan, Centauri Republic
