From owner-freebsd-security@FreeBSD.ORG Thu Apr 10 13:48:17 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 573BC474 for ; Thu, 10 Apr 2014 13:48:17 +0000 (UTC) Received: from mail.koukaam.se (mail.koukaam.se [193.86.201.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mail.koukaam.se", Issuer "KOUKAAM Certificate Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id BA20D14DA for ; Thu, 10 Apr 2014 13:48:13 +0000 (UTC) Received: from [192.168.1.41] (unassigned-81-90-254-125.ujezd.net [81.90.254.125] (may be forged)) (authenticated bits=0) by mail.koukaam.se (8.14.5/8.14.5) with ESMTP id s3ADdqVM004523 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 10 Apr 2014 15:40:02 +0200 (CEST) (envelope-from knezour@weboutsourcing.cz) Message-ID: <53469F27.90509@weboutsourcing.cz> Date: Thu, 10 Apr 2014 15:39:51 +0200 From: Ondra Knezour User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: "Ronald F. Guilmette" , freebsd-security@freebsd.org Subject: Re: Heartbleed, a few naive questions References: <42638.1397124000@server1.tristatelogic.com> In-Reply-To: <42638.1397124000@server1.tristatelogic.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Apr 2014 13:48:17 -0000 Dne 10.4.2014 12:00, Ronald F. Guilmette napsal(a): > Rather, I was asking, albeit indirectly, whether a program or > library, such as OpenSSL, which is primarily a security-forcused > tool, and upon which a significant fraction of online humanity > depends for its security, is deserving of a "belt and suspenders" > sytle of defensive programming. > [..] > (And by the way, it would not be a terribly difficult thing to add to > any C compiler a new option that, when used during compilation of > select "mission critical" secirity software, would have the effect of > generating code for each function that completely zeros at least the > statically-sized part of the new stack frame upon entry to the > function, or conversely would generate code which would zero the > current frame just before function exit. Such an option might be > useful when compiling critical security code, such as the OpenSSL > library, and if it had been available and used in conjunction with > allocation of the problematic buffer on the stack, as I suggested, I > believe that those steps, taken together would have eliminated even > the possibility of leakage of server-specific secrets. You can have all those safety nets in the code, functions, compilers, but there will be a day, when some creative person will do some creative "optimization" in name of speed, efficiency, whatever. The compiler is forcing zeroing of buffer on allocation in case of size_of buffer is known on compile time? Let it be size_of int + size_of last_tcp_fragment, yeah, we got them. Following thread comes on my mind all the time reading your message http://www.mail-archive.com/misc@openbsd.org/msg128161.html (I don't know which platforms are refered as slow, but it would be funny if we are talking about architecture of which last machine standing was just moved in museum between the computing and paleolitic departments.) -- Ondra