Date: Tue, 22 Apr 2014 18:34:00 -0600 From: Chad Perrin <code@apotheon.net> To: "Ronald F. Guilmette" <rfg@tristatelogic.com> Cc: freebsd-security@freebsd.org Subject: Re: OpenSSL static analysis, was: De Raadt + FBSD + OpenSSH + hole? Message-ID: <20140423003400.GA8271@glaze.hydra> In-Reply-To: <8783.1398202137@server1.tristatelogic.com> References: <DC2F9726-881B-4D42-879F-61377CA0210D@mac.com> <8783.1398202137@server1.tristatelogic.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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, 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 ]
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20140423003400.GA8271>