From owner-freebsd-security@FreeBSD.ORG Fri Apr 25 13:52:34 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 BB6D7B40 for ; Fri, 25 Apr 2014 13:52:34 +0000 (UTC) Received: from gate2.quietfountain.com (gate2.quietfountain.com [97.64.213.195]) by mx1.freebsd.org (Postfix) with ESMTP id 821671688 for ; Fri, 25 Apr 2014 13:52:34 +0000 (UTC) Received: from ops1.quietfountain.com (ops1.quietfountain.com [192.168.29.13]) by gate2.quietfountain.com (Postfix) with ESMTP id 248EEB80AA for ; Fri, 25 Apr 2014 08:52:28 -0500 (CDT) To: freebsd-security@freebsd.org Date: Fri, 25 Apr 2014 08:52:10 -0500 Subject: Re: OpenSSL static analysis, was: De Raadt + FBSD + OpenSSH + hole? References: <23494.1398337629@server1.tristatelogic.com> <697C2D01-D8F7-4BC4-BBED-6B4A93105E62@cederstrand.dk> <20140424174914.GC3850@glaze.hydra> Message-ID: <535A688A.2040606@quietfountain.com> From: "hcoin" Received: from [192.168.29.127] (gate1.quietfountain.com [192.168.29.2]) by ops1.quietfountain.com; Fri, 25 Apr 2014 08:52:11 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.17 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: Fri, 25 Apr 2014 13:52:34 -0000 On 04/24/2014 12:49 PM, Chad Perrin wrote: > On Thu, Apr 24, 2014 at 01:59:10PM +0200, Erik Cederstrand wrote: >> Den 24/04/2014 kl. 13.07 skrev Ronald F. Guilmette : >>> Sir, does not the following trivial and obvious single line modification >>> to the above code eliminate the warning? And does it not do so *without* >>> the need for ``considerable effort''? >>> >>> int x = -1; >>> >>> I thank you for providing me with the example above, and thus also this >>> opportunity to so perfectly illustrate my fundamental point. >> The example I gave is of course trivial to rewrite. It was the >> shortest possible example I could think of to illustrate the >> situation. It was condensed from a really convoluted if-else case >> which was not incorrect but quite difficult to untangle. And yes, it's >> laudable to rewrite it for the sake of readability, but it doesn't fix >> any security issues. > I'm generally of the opinion that, all else being equal, making your > code readable is a way to find bugs you did not know existed. Even more > amazingly, making your code readable fixes bugs that have not yet been > written. > +1. As an exercise, writing a small but non-trivial program in machine 'assembly' language that has to deal with at least one interrupt drives Mr. Perrin's lesson home better than any number of lectures. Let's not kid ourselves though, the only 'assurance' anyone can give about the security of any non-trivial bit of programming is what they detect upon manual review, and by use of programs that detect problems (which today are not more than automating a subset of mostly syntax-related things we look for upon manual review). These are 'consensus security opinions' or 'somewhat justified true beliefs'. Until checking programs also encompass more semantics, until we can write a collection of what in logic would be called axioms (which when all true for a program /a fortior//i/ imply security) well..... it would be better to avoid having to eat future dishes of hot steaming crow by terming software security 'security arts', akin to 'medical arts'. Harry Coin