Slashdot Mirror
OpenSSL To Undergo Massive Security Audit
rjmarvin writes Now that its codebase is finally viewed as stable, OpenSSL is getting a good top-to-bottom once-over in the form of a sweeping audit. As part of the Linux Foundation's Core Infrastructure Initiative, the foundation and the Open Crypto Audit Project are sponsoring and organizing what may arguably be the highest-profile audit of a piece of open-source software in history. The audit itself will be conducted by the information assurance organization NCC Group, and its security research arm, Cryptography Services, will carry out the code review of OpenSSL's 447,247 line codebase over the next several months.
Code cannot be claimed to be secure unless it has been designed with secure design patterns - patterns for which there is an "assurance argument". If the code was "coded" instead of designed, then there is no hope of creating assurance arguments after the fact. In that case, the audit will be very difficult and untrustworthy.
Seems a bit late... Should have started the audit soon after the Heartbleed bug was found, not 11 months later.
Better get ready for 1000 posts Fundraising for OpenBSD with the LibreSSL project.
Just remember, every dollar you donate for LibreSSL is not guaranteed to be spent on it, it goes into the general fund for OpenBSD.
Why bother with a security audit of the whole OpenSSL as-is, right here, right now, when the LibreSSL fork has been doing a lot of work removing years of unmaintained cruft (cf. http://en.wikipedia.org/wiki/L...) ? It seems to be an exercise in futility... I also wonder why get the job to a private company, which would certainly result in very bad transparency, when they could just launch a bounty program rewarding exploits & bug findings ?!?
NCC Group, and its security research arm, Cryptography Services, will carry out the code review
In related news, NCC Group today received 37 applications from extraordinary qualified candidates, all of whom -- by some extraordinary coincidence -- live in Langley, VA.
Stop-Prism.org: Opt Out of Surveillance
you can wait a year for their results or just use libressl today. They've already identified, deleted, and/or fixed hundreds of bugs.
Copyright (c) 1990 - 2014 Dice. All rights reserved. Use of this comment is subject to certain Terms and Conditions.
Now that its codebase is finally viewed as stable, OpenSSL
Finally? As compared to what? The other 30-50 stable releases since it's creation in 1998, as a replacement / update for SSLeay (which was written by Eric Young and Tim Hudson)?
.
It's also one of the funniest developer-centric things I've ever read - no holds barred for these guys in their contempt of the code they're ripping to shreds. Win/win.
I don't think it is possible to secure 447,247 lines of code. I thought there was a chance before I saw that number.
Here's the best part: they can audit the security of nearly a half a million lines of code in "several months".
... every which way to Sunday.
I'm a fan of both libressl and this project. Now we will have two dedicated groups working on improving the security of SSL. There will no doubt be sharing of findings, and both products will improve as a result.
SSLeay and OpenSSL have been neglected for too long. It's boring to work on this software, but that doesn't mean the work is not important.
You don't need to look for kidney stones in bone marrow. Most likely what they are doing is better described by "screening" rather than "auditing" even though the later is the conventional word.
Algorithms (such as ciphers) tend to be fairly easy to cover with test suites, whereas memory management and handling of randomness sources are both fraught with peril and difficult to formally test.
It really helps to reduce audit coverage if your code analysis tools can eliminate big chunks of code as purely functional with no side-effects on system state. A purely functional function would not include code that performs heap-based memory allocation, and would exclude the vast majority of system calls.
Even so, I suspect there's a pretty steep gradient on where to direct your best attention to identify misguiding coding constructs (approaches that are worse than wrong)—if you're not determined to check for identify kidney stones lurking in bone marrow.
You don't need to look for kidney stones in bone marrow.
True enough, but which is the best organ in the code corpus to look for buffer overruns?
Your idea of using tools to whittle down the haystack in order to focus the search for needles seems like a good one, but do such security auditing tools already exist? If not, about the only automatic thing I could think of that you could get going in a short time over such a large body of code would be lint or similar static checking tools.
I've worked with a corpus of crypto code which consists of a collection of many of the most well known algorithms. None of the algorithms are very large or complicated individually, though many use "cryptic" [tee-hee] tables that seem pretty opaque to the non-expert. I don't know such table would be easy or hard for the expert to verify, but in my case, I just had to assume they were right. But if the OpenSSL code being audited (screened) consists of a half a million lines, there must be a lot more complicated things going on in it.
.
While audits are nice, what are the OpenSSL developers doing to change the development environment so that the new, [hopefully] improved versions don't revert to the security-challenged versions we've all come to know?
It's easy to change code, much less easy to change developer attitudes.
It very much depends. Often you only need to secure key interfaces and key functionality. Everything that fails securely (e.g. non-functional), for example, does not need to be audited.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
In all seriousness: who are these institutions? And do they have bullet-proof methods to warn everyone when (probably not if) they receive NSLs to ignore and keep certain code in place, upon pain of PMITA prison time?