Date: Wed, 23 Apr 2014 11:00:54 +1000 From: Mark Andrews <marka@isc.org> To: "Ronald F. Guilmette" <rfg@tristatelogic.com>, freebsd-security@freebsd.org Subject: Re: OpenSSL static analysis, was: De Raadt + FBSD + OpenSSH + hole? Message-ID: <20140423010054.2891E143D098@rock.dv.isc.org> In-Reply-To: Your message of "Tue, 22 Apr 2014 18:34:00 -0600." <20140423003400.GA8271@glaze.hydra> References: <DC2F9726-881B-4D42-879F-61377CA0210D@mac.com> <8783.1398202137@server1.tristatelogic.com> <20140423003400.GA8271@glaze.hydra>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <20140423003400.GA8271@glaze.hydra>, Chad Perrin writes: > On Tue, Apr 22, 2014 at 02:28:57PM -0700, Ronald F. Guilmette wrote: > > In message <DC2F9726-881B-4D42-879F-61377CA0210D@mac.com>, > > Charles Swiger <cswiger@mac.com> wrote: > > > > > >Bug Type Quantity > > >All Bugs 182 > > > > > >Dead store > > > Dead assignment 121 > > > Dead increment 12 > > > Dead initialization 2 > > > > > >Logic error > > > Assigned value is garbage or undefined 3 > > > Branch condition evaluates to a garbage value 1 > > > Dereference of null pointer 27 > > > Division by zero 1 > > > Result of operation is garbage or undefined 9 > > > Uninitialized argument value 2 > > > Unix API 4 > > > > Thank you for doing this. > > > > Perhaps it goes without aying, but I'll say it anyway. The above results > > are at once both enlightening and disgusting. > > > > Apparently, the OpenBSD guys are reorganizing/rewriting OpenSSL. I hope > > that they take the time to do what you have done *and* also to drive every > > bleedin' last one of these numbers to zero. I feel sure that the vast > > majority of the issues uncovered by clang are not in any sense exploitable, > > however its the one or two or three that are that worry me. > > LibreSSL (re: reorganizing/forking OpenSSL). I'm sure they'll be doing > a very thorough job, as LibreSSL will apparently be added to the full > body of code managed and extensively code-reviewed by the OpenBSD > project. The developers are also taking the encouraging first step of > throwing away eight metric tons of cruft. I do not know whether they > plan to specifically use Clang's static analyzer as an aid to their > efforts, but I would guess they'll be taking similar measures. > > >From what I have seen (which, admittedly, is pretty superficial by many > standards), it looks like OpenSSL is probably just the best of a really > bad breed of software. The most widespread, popular, by some standard > "major" TLS packages all seem to be rancid crap, with OpenSSL just being > the marginally least rancid of the lot. If something like the heartbeat > leak exists in OpenSSL, I fully expect that the other big players have > worse problems. Consider for instance that (real-world impact aside) > the heartbeat bug was the result of a failure of secure coding that took > the form of a fairly common way for people to overlook memory management > problems in C, Heartbleed had NOTHING to do with memory managment. It was a input parsing bug plain and simple. Standard malloc would not have helped one iota. Even turning on no standard malloc features like overwrite on free was not guarenteed to help. All that does is reduce the amount of memory with data that could be read. It does not prevent active memory being read. As for the number of CLANG analysis warnings. Clang has false positives some of which are impossible to remove regardless of how you recode the section and most of what was reported will be benign. We use clang, Coverity and other tools all the time on products we ship. We use multiple compilers and each one of them pick up different things. Even after doing all that and removing all the warning we can we have to mark things as "Ingore - false positive" or "Ignore - Intentional" as the analyser doesn't follow all of the assignments or doesn't handle initialisation code that doesn't need to be locked or ..... > while the validation issues recently unearthed in Apple > and GnuTLS encryption packages were the sorts of errors that are rather > uncommon for people to overlook, in that it almost takes a malicious act > of stupidity to forget to *use* an otherwise correct validation, right > there in the code where it took place. > > Even if LibreSSL ends up only halving the vulnerability that comes with > OpenSSL (which is, I think, a quite inadequate level of improvement), it > should end up being a fantastic leap forward, putting OpenSSL itself in > a distant second place over alternatives. > > I'm mostly just hand-waving, though. If someone with deeper insight > into the guts of these TLS packages offer contradicts me in some way > with actual independently verifiable supporting analysis, you should > probably believe that person. > > > > > > P.S. I was reading last night about VP8. In that case, apparently, > > the formal specification for that protocol *is* the code. (See RFC > > 6386, Section 1.) > > > > If you have time, Charles, perhaps you could run this same analysis on > > that code too, and report numbers for that as well. > > > > I am *not* looking forward to the day when I'll be rooted because I was > > watching funny kitten videos on YouTube. > > Solution: Dont' watch funny kitten videos on YouTube. > > I kid. I know it's impossible to stop watching funny kitten videos. A > useful mitigation, however, might be to never log in to any Google > service, and avoid HTTPS URIs for Google services when you must visit > them. > > -- > Chad Perrin [ original content licensed OWL: http://owl.apotheon.org ] > _______________________________________________ > freebsd-security@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-security > To unsubscribe, send any mail to "freebsd-security-unsubscribe@freebsd.org" -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20140423010054.2891E143D098>