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.

Must be designed secure - not "coded"

[cjonslashdot]

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.

Re:

[garyisabusyguy]

This paper seems to indicate that the capability of the random number generator varies based on implementation, if this is the case then it seems that the foundation for OpenSSL is suspect. Will rand and prng be part of the audit (they were not mentioned in the linked article)

ABSTRACT OpenSSL is the most widely used library for SSL/TLS on the Android platform. The security of OpenSSL depends greatly on the unpredictability of its Pseudo Random Number Generator (PRNG). In this paper, we reveal the vulnerabil

Re:

[Anonymous Coward]

I absolutely agree with you on this, but it is a good first step, IMO. We have to start somewhere. Unfortunately, a lot of FOSS is "coded" and not "designed". If anyone asks me to code something, I tell them that is not how I do it - 80-90% design, 10-20% code. That's my rule of thumb!

Re:Must be designed secure - not "coded"

[nightsky30]

Couldn't the first step be libreSSL? They cleaned out a ton of junk and applied some uniform coding standards. That would be much easier to audit, and a much sounder base.

Re:Must be designed secure - not "coded"

[arglebargle_xiv]

Couldn't the first step be libreSSL? They cleaned out a ton of junk and applied some uniform coding standards. That would be much easier to audit, and a much sounder base. Flag as Inappropriate

Exactly (no mod points left, sorry). Auditing OpenSSL makes about as much sense as auditing Windows 95, we already know it's broken beyond repair, and any further effort expended on it is just throwing good money after bad. Focus on something that's worth going with, like LibreSSL, or something that was never OpenSSL to begin with.

Re:

[ezdiy]

For what it's worth, NCC is not some self-appointed security snake oils but industry behemot who actually does software assurance. They harbor a lot of auditing talent (iSEC partners from top of my head).

Conversely, your nirvana fallacy does not hold up. OpenBSD was "designed" to be secure, just to become a laughing stock for reasons you outlined. All code without formal proof (ie all of systems code written in C) is potentially vulnerable no matter what. All you can do is throw best auditing talent at i

Re:

[cjonslashdot]

I am not saying that having an assurance argument makes code secure. I am saying that without one, it is very hard to reverse engineer the security model and thereby convince oneself that the code is secure.

Re:

[gweihir]

Actually, I disagree. Assurance arguments do not necessarily help. They can make the overall view a lot more complex and a lot harder (or even impossible) to evaluate. An example one of my CS professors gave may illustrate this: A company had a full formal specification for a piece of software. They wanted a security evaluation of it based on that specification. That proved to be impossible: It was 2 meters of regal space printed out and completely beyond the capabilities of any human or automated evaluati

Re:

[cjonslashdot]

Yes, I agree with what you say. You misunderstood the intent of what I said. I was not arguing for formal proofs. By "assurance argument" I merely meant that the programmer uses some explicit design patterns, that can be analyzed: the "assurance argument" is merely the logical analysis that convinces the programmer that the pattern is a secure pattern. Thus, I claim that secure code does not start as code, but starts as diagrams (design patterns) and algorithms that are then turned into code. The assurance

Re:

[gweihir]

I see. That makes a lot more sense.

But usually you cannot leave the code out from the argument, there are just far too many vulnerabilities that result from technical details. Hence I believe this can be done in any number of fashions, but at the end, there is a sound argument _why_ this particular piece of code is secure on algorithmic and on code level and that gets attached to the code.

Re:

[Ralph Siegler]

Laughingstock? Most open source OS use code done by the OpenBSD team, as well as big vendors including Cisco, Juniper, even Microsoft (in the Unix services suite) etc. Your "formal proof" languages have been used for projects with bugs that have failed, maimed and killed people, exploded. There's a laughingstock, you spout ivory tower idealism that doesn't hold in real world.

Re:

[wiredlogic]

I don't think OpenSSL was even coded. It reads like an OOP nightmare.

Re:

[ezdiy]

The same story for a lot of old and hairy codebases. Try glibc some day if you really want to see things.

Re:

[gweihir]

That sounds like policy-believer nonsense. Security is not a top-down thing, it _always_ needs to be evaluated in a holistic way. That is what it makes security so hard, you cannot just use the right "tool" or "method" or "policy". That does not work at all.

While policies, methods, etc. cannot make you secure, actual code can be secure or not. It is always funny when I explain to clients why all their compliance and adherence to policies, standards and methods does not make them secure, but does quite often

Re:

[cjonslashdot]

Yes, you are right. But I was not speaking from a "policy" perspective. I was saying essentially what you are trying to say: security is holistic. What I was trying to say, apparently not very well, is that secure code must be based on a secure design. If you hack something together, without explicitly analyzing your design patterns, you have no way to convince yourself that is secure. This is not about policy: it is about sound design. As Peter Neumann once said, "Good system and network architecture is pe

Re:

[gweihir]

Ok, misunderstanding cleared up.

Well, I firmly believe the whole design-pattern movement is a failure, and even more so for security. Sure, incompetent coders can get up to maybe semi-competent with it, but that is basically it. For secure code, you need to understand everything, and pre-made patterns abstract necessary detail away. At the same time, the "vocabulary" that you get and that some people praise may help on simplistic (but large) systems, but generally also suffers from abstracting necessary det

Re:

[cjonslashdot]

Well said. I actually agree with all of this. When I use the term "design pattern", I am speaking generally - not in terms of the "design pattern" movement. I simply mean defining the design in some way - not just rushing to the keyboard and coding. As you put it, you need all three: good architecture, good design, and good implementation. Many programmers today skip the first two.

I'm gonna FREAK!

[Anonymous Coward]

Seems a bit late... Should have started the audit soon after the Heartbleed bug was found, not 11 months later.

Re:I'm gonna FREAK!

[Ralph Siegler]

A team with leadship in the realm of secure software already did that, starting about 11 months ago. The OpenSSL code didn't just need audited, it need large swaths of code thrown in the trash, and code refactored for security, readability, and ease of debugging. And fixes made. Which is being done. http://www.libressl.org/ [libressl.org]

Re:

[ezdiy]

A team with leadship in the realm of security

Yes, some people take an issue with that, fe:

https://blog.hboeck.de/archive... [hboeck.de]

Some naysayers are of the opinion that Theo & his peck are good at writing well designed software from scratch (eg openssh), however their "securing" of existing codebases (eg bsd kernel and libc) ended up in trainwreck. libressl is sadly the case of the latter.

Re:I'm gonna FREAK!

[Noryungi]

Oh, really? A trainwreck?

Explain this, then: [Source is here [undeadly.org]]

The following CVEs were fixed in earlier LibreSSL releases:
              CVE-2015-0206 - Memory leak handling repeated DLTS records
              CVE-2014-3510 - Flaw handling DTLS anonymous EC(DH) ciphersuites.

            The following CVEs did not apply to LibreSSL:
              CVE-2014-3571 - DTLS segmentation fault in dtls1_get_record
              CVE-2014-3569 - no-ssl3 configuration sets method to NULL
              CVE-2015-0204 - RSA silently downgrades to EXPORT_RSA

Let's see... 5 CVE were either fixed in LibreSSL or did not apply to it. That's not too bad for a "trainwreck".

And what about that little dig at NetBSD [tedunangst.com]? Hmmmm... You mean some people take stuff from OpenBSD and make it less secure? The plot thickens.

Oh, and by the way, that OpenSSH thingie? Yup, it came from the last "open source" version of SSH [wikipedia.org], the commercial software. In other words, OpenBSD devs took something already existing and made it better. Hmmm... I think you just don't know what you are talking about...

Listen, you can find OpenBSD programmers annoying and even call them "masturbating monkeys [hackerco.de]", but they know their stuff. Period. Calling what they do a "trainwreck" is hyperbole at best and just plain untrue at worst.

This being said, to get back on topic, auditing OpenSSL is not a bad idea. Far from it.

Re:

[Ralph Siegler]

A lot of obsolete and archaic functionality no one was using is gone. Very unsecure code that was blindly rubber-stamped for FIPs compliance by people only concerned for money rather than security is gone. You then mention bug that was fixed last July 2014 with random pools. The two maintainersadmit they don't understand the code, too much slapped together over too long by too many Finally we have something the hands of security gurus, who are cleaning up the code, who are doing project in transparent

Re:

[Ralph Siegler]

You link to something from July 2014, when libressl project is four months old that mentions issues? Massive changes happened since then. How is libressl or their kernel work (like say W^X in amd-x64 kernel, or their randomizing of allocation, tcp properties, etc.) a "trainwreck"?

Re:

[Ralph Siegler]

In your face, libressl doesn't have the pile of vulnerabilities just announced with openssl, because in most cases the crap removed, and one because proper design done:

DOES NOT APPLY TO LIBRESSL 2.1.6

* CVE-2015-0291 - OpenSSL 1.0.2 ClientHello sigalgs DoS
Affected code is not present.
* CVE-2015-0290 - Multiblock corrupted pointer

Re:

[nightsky30]

THANK YOU! :)

Re:

[ShanghaiBill]

Seems a bit late... Should have started the audit soon after the Heartbleed bug was found, not 11 months later.

They were waiting for the NSA to approve the funding.

Re:

[gweihir]

The timing is good and adequate: If you know you need to clean things up, then you clean them up _before_ you audit. Everything else just wastes audit resources.

Que 1000 posts fundraising for openbsd

[rahvin112]

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.

Re:Que 1000 posts fundraising for openbsd

[rubycodez]

Are you claiming the misrepresent where funding goes on the LibreSSL site?

"LibreSSL is supported financially by the OpenBSD Foundation and the OpenBSD Project. Please consider helping our efforts.

OpenBSD team still lightyears ahead getting the bad code out of openssl; this "audit" will not do as well as they have already done

Re:

[rahvin112]

I'm claiming they are technically telling the truth and don't care if someone misunderstands.

A person not knowledgeable about how the foundation is structured and donations are spent might be misled to believe that a donation made to the foundation for the purposes of LibreSSL would be spent on LibreSSL and they are happy to let that misunderstanding take place. Rather than be completely clear about not just what bank account they stick the money in but how it will be spent is an important detail that they

Not the time...

[x0ra]

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... [wikipedia.org]) ? 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 ?!?

Re:

[Anonymous Coward]

Because your solution presents fewer opportunities for the NSA to get their fingers on the project and insert flaws and backdoors.

Mod me down if you want, but that doesn't mean it's not true.

Re:

[Anonymous Coward]

I know right!!! Screw OpenSSL. They may be all corporate centric, but they've had years upon years of repeated vulnerabilties.
LibreSSL, OpenBSD, and Theo's crew have always taken a hardcore stance on things and that's valuable.
I'm with LibreSSL. Go Go Go LibreSSL.

Re:

[Anonymous Coward]

But then how could they charge all that sweet consulting money?

OpenSSL Valhalla Rampage blog

[thatseattleguy]

Perhaps here is a good place to mention that you could learn more about real-world security auditing and code hardening by reading the LibreSSL developer's comment log here [opensslrampage.org], billed as "Tearing apart OpenSSL, one arcane VMS hack at a time."

.
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.

Re:

[bill_mcgonigle]

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

Presumably the audit was bid fixed-cost. Presumably these guys already built into the cost that they are going to build upon the work the LibreSSL team has done (it would be stupid not to).

LibreSSL is a great project, but they ripped out portability along the way. A fair argument can be made that it's easier to add portability back after all the crap is ripped out, but fi

Re:Not the time...

[Noryungi]

LibreSSL is a great project, but they ripped out portability along the way.

Excuse me??!! Just like OpenSSH, they release a portable version, and the official release note says [undeadly.org]:

This release also includes a binary package for convenience integrating LibreSSL on Windows platforms, and the latest source tarball is signed with GPG and signify for easier integration into existing build systems.

We are talking about Windows, here... Sure, if you are into Windows 3.11 and VMS, LibreSSL is less portable than OpenSSL. But seriously, who even uses these two anymore??!!

OK, I'll grant you that LibreSSL is not a complete replacement for OpenSSL just yet. OpenBSD devs prefer working on their favourite OS, and I can't blame them. This being said, I would not be surprised if, in a couple of years, the rest of the world has switched to LibreSSL and forgotten the older version -- just take a look at OpenSSH... ;-)

Re:

[zyche]

LibreSSL is a great project, but they ripped out portability along the way.

[Citation needed]

In Related News...

[Bob9113]

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.

Canaries

[ThatsNotPudding]

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?

Re:It is too much code to secure.

[Marginal Coward]

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".

Re:

[epine]

Here's the best part: they can audit the security of nearly a half a million lines of code in "several months".

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 real

Re:

[Marginal Coward]

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

Re:

[gweihir]

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.

For those that don't want to wait a year:

[slashdice]

you can wait a year for their results or just use libressl today. They've already identified, deleted, and/or fixed hundreds of bugs.

Huh?

[plcurechax]

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)?

Re:

[cant_get_a_good_nick]

Finally in this case refers to the cleanup after the Heartbleed mess. Yeah, those releases were marked stable, but in this context, the auditors expected massive code shifts immediately post-Heartbleed and decided not worth the time to audit code that was possibly being culled anyway. They still had Win95 code for example, do you audit that? VAX code?

Re:

[Anonymous Coward]

OepnSSL supports big-endian x86, in case Intel decided to change their mind. Good luck testing the code for this hypothetical arch.

They will break it...

[jtara]

... every which way to Sunday.

Re:

[cbhacking]

It's an audit, not a re-write. The results of the audit may drive re-writes, and the re-writes may lead to code breakage or at least loss of compatibility, but that's irrelevant to the audit itself. This is essentially a read-only review. It's definitely not a fork, a la LibreSSL.

Great

[jgotts]

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.

Product of its environment

[QuietLagoon]

Software quality is representative of the environment that created 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.