Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
Encryption The Internet

OpenSSL To Undergo Massive Security Audit 69

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.
This discussion has been archived. No new comments can be posted.

OpenSSL To Undergo Massive Security Audit

Comments Filter:
  • by cjonslashdot ( 904508 ) on Thursday March 12, 2015 @02:32PM (#49243993)
    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.
    • 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

    • by 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: (Score:2, Interesting)

      by ezdiy ( 2717051 )
      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
      • 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.
        • by gweihir ( 88907 )

          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

          • 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
            • by gweihir ( 88907 )

              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.

      • 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.
    • I don't think OpenSSL was even coded. It reads like an OOP nightmare.

      • by ezdiy ( 2717051 )
        The same story for a lot of old and hairy codebases. Try glibc some day if you really want to see things.
    • by gweihir ( 88907 )

      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

      • 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
        • by gweihir ( 88907 )

          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

          • 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! (Score:2, Insightful)

    by 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! (Score:5, Informative)

      by Ralph Siegler ( 3506871 ) on Thursday March 12, 2015 @02:52PM (#49244165)
      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]
      • by ezdiy ( 2717051 )

        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! (Score:5, Informative)

          by Noryungi ( 70322 ) on Thursday March 12, 2015 @04:18PM (#49244943) Homepage Journal

          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.

        • 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"?
        • 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

      • THANK YOU! :)
    • 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.

    • by gweihir ( 88907 )

      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.

  • by rahvin112 ( 446269 ) on Thursday March 12, 2015 @02:36PM (#49244019)

    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.

    • by rubycodez ( 864176 ) on Thursday March 12, 2015 @02:42PM (#49244065)

      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

      • 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... (Score:5, Interesting)

    by x0ra ( 1249540 ) on Thursday March 12, 2015 @02:38PM (#49244039)
    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: (Score:1, Interesting)

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

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

    • by Anonymous Coward
      But then how could they charge all that sweet consulting money?
    • by thatseattleguy ( 897282 ) on Thursday March 12, 2015 @03:19PM (#49244385) Homepage
      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: (Score:2, Informative)

      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... (Score:4, Interesting)

        by Noryungi ( 70322 ) on Thursday March 12, 2015 @04:25PM (#49244995) Homepage Journal

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

      • by zyche ( 784345 )

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

        [Citation needed]

  • by Bob9113 ( 14996 ) on Thursday March 12, 2015 @02:51PM (#49244159) Homepage

    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.

    • 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?
  • you can wait a year for their results or just use libressl today. They've already identified, deleted, and/or fixed hundreds of bugs.
  • 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)?

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

      • by Anonymous Coward
        OepnSSL supports big-endian x86, in case Intel decided to change their mind. Good luck testing the code for this hypothetical arch.
  • ... every which way to Sunday.
    • 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.

  • by jgotts ( 2785 )

    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.

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

"All my life I wanted to be someone; I guess I should have been more specific." -- Jane Wagner

Working...