[gentoo-dev] Akamai secure memory allocator for OpenSSL?

[Joshua Kinard]

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
kumba@g.o
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