Date: Fri, 25 Apr 2014 08:52:10 -0500 From: "hcoin" <hcoin@quietfountain.com> To: freebsd-security@freebsd.org Subject: Re: OpenSSL static analysis, was: De Raadt + FBSD + OpenSSH + hole? Message-ID: <535A688A.2040606@quietfountain.com> References: <23494.1398337629@server1.tristatelogic.com> <697C2D01-D8F7-4BC4-BBED-6B4A93105E62@cederstrand.dk> <20140424174914.GC3850@glaze.hydra>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <rfg@tristatelogic.com>: >>> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?535A688A.2040606>