From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id 8110F138A1F for ; Mon, 14 Apr 2014 08:48:47 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 1791EE0BC3; Mon, 14 Apr 2014 08:48:42 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 13346E0B99 for ; Mon, 14 Apr 2014 08:48:41 +0000 (UTC) Received: from [192.168.178.100] (xdsl-31-165-146-235.adslplus.ch [31.165.146.235]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: dev-zero) by smtp.gentoo.org (Postfix) with ESMTPSA id F34DB33FD70 for ; Mon, 14 Apr 2014 08:48:39 +0000 (UTC) Message-ID: <534BA0E3.5010609@gentoo.org> Date: Mon, 14 Apr 2014 10:48:35 +0200 From: =?ISO-8859-1?Q?Tiziano_M=FCller?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Akamai secure memory allocator for OpenSSL? References: <534AF6A8.6070001@gentoo.org> In-Reply-To: <534AF6A8.6070001@gentoo.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Archives-Salt: 2f1acb65-3915-4618-a3ca-f026393f945a X-Archives-Hash: 8a069df2dc5ede86fb3ad76a6883a587 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