Am 13.04.2014 22:42, schrieb 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)?
Not really, no. I would rather wait until other people have reviewed and/or it has been pulled into openssl. To cite the Akamai dev who posted the patch [1]: "Let me restate that: *do not just take this patch and put it into production without careful review.*" Best, Tiziano [1] http://thread.gmane.org/gmane.comp.encryption.openssl.user/51243?resub=1
