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

[Toralf Förster]

On 04/14/2014 10:48 AM, Tiziano Müller wrote:
> 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.
>

And for the same reason I'd like to see that the hpn USE flag in the
package openssh would have the default value "off"
(recent discussion at the mailing list around 3/29)


> 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
>
>


-- 
Toralf