| 1 |
Am 13.04.2014 22:42, schrieb Joshua Kinard: |
| 2 |
> So one of the side-discussions happening after Heartbleed was the fact that |
| 3 |
> OpenSSL has its own memory allocator code that effectively mitigates any C |
| 4 |
> library-provided exploit mitigations (as discussed on the openbsd-misc ML at |
| 5 |
> [1] and Ted Unangst's blogs at [2] and [3]). This is partially why there's |
| 6 |
> so much "interesting" data to be sniffed from a server's memory via the |
| 7 |
> heartbleed response packets -- that memory wasn't really initialized to |
| 8 |
> random data or zero'd upon malloc(), nor garbage-collected upon free(). |
| 9 |
> |
| 10 |
> Taking place over on the openssl-users ML, someone from Akamai posted a new |
| 11 |
> secure memory allocator patch[4][5] that they have been using in production |
| 12 |
> for about a decade. That patch was cleaned up, diff'ed against |
| 13 |
> openssl-1.0.1g, and posted to openssl-dev here: |
| 14 |
> https://marc.info/?l=openssl-dev&m=139733477712798&q=p5 |
| 15 |
> |
| 16 |
> It basically provides a secure memory area protected by guard pages for |
| 17 |
> sensitive data, like RSA private keys, so that if another Heartbleed-like |
| 18 |
> event occurs, things won't be as bad. Hopefully... |
| 19 |
> |
| 20 |
> Is this something we want to look at adding to our openssl copy via an |
| 21 |
> optional USE flag (default off)? |
| 22 |
|
| 23 |
Not really, no. I would rather wait until other people have reviewed |
| 24 |
and/or it has been pulled into openssl. |
| 25 |
|
| 26 |
To cite the Akamai dev who posted the patch [1]: |
| 27 |
"Let me restate that: *do not just take this patch and put it into |
| 28 |
production without careful review.*" |
| 29 |
|
| 30 |
Best, |
| 31 |
Tiziano |
| 32 |
|
| 33 |
[1] http://thread.gmane.org/gmane.comp.encryption.openssl.user/51243?resub=1 |
Archives