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

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

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

[Patrick Lauer]

On 04/14/2014 04:42 AM, Joshua Kinard wrote:
> 
> 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]). 
[snip good explanation]

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

http://lekkertech.net/akamai.txt

> Is this something we want to look at adding to our openssl copy via an
> optional USE flag (default off)?

At this point in time I'd say we better wait for the storm to settle
down - apparently the akamai patches are only fixing a small part of the
problem.

I don't have a strong opinion as I haven't had to think about the
internals of crypto software in a while, but hastily adding
not-well-reviewed code might not be the best strategy.

Have fun,

Patrick

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

[Joshua Kinard]

On 04/13/2014 20:17, Patrick Lauer wrote:
> On 04/14/2014 04:42 AM, Joshua Kinard wrote:
>>
>> 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]). 
> [snip good explanation]
> 
>> 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...
> 
> http://lekkertech.net/akamai.txt

I was not aware of that write up.  Nice find!  That effectively rules this
patch out.


>> Is this something we want to look at adding to our openssl copy via an
>> optional USE flag (default off)?
> 
> At this point in time I'd say we better wait for the storm to settle
> down - apparently the akamai patches are only fixing a small part of the
> problem.
> 
> I don't have a strong opinion as I haven't had to think about the
> internals of crypto software in a while, but hastily adding
> not-well-reviewed code might not be the best strategy.

Agreed.  Crypto is not my strong suite, but I thought I'd see what others
thought on the patch.  Someone is either going to step up and really "fix"
OpenSSL or the community will eventually nominate a replacement for it (ala
XFree86 -> Xorg).

-- 
Joshua Kinard
Gentoo/MIPS
kumba@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

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

[Tiziano Müller]

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

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

[Rémi Cardona]

Le lundi 14 avril 2014 à 10:48 +0200, Tiziano Müller a écrit :
> 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.*"

http://lekkertech.net/akamai.txt

I, for one, am glad we didn't pull this in right away. OpenSSL is under
a lot of scrutiny now, so let's not rush any patches.

Cheers

Rémi

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