Slashdot Mirror

← Back to Stories (view on slashdot.org)

OpenSSL To Undergo Massive Security Audit

Posted by timothy on from the cracking-down-on-cracking-down dept.

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.

69 comments

  1. Must be designed secure - not "coded" by cjonslashdot · · Score: 4, Informative

    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.

    1. Re:Must be designed secure - not "coded" by garyisabusyguy · · Score: 1

      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 vulnerability of the OpenSSL PRNG on the Android
      http://www.researchgate.net/pu...

      --
      Wherever You Go, There You Are
    2. Re:Must be designed secure - not "coded" by Anonymous Coward · · Score: 1

      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!

    3. Re:Must be designed secure - not "coded" by ezdiy · · Score: 2, Interesting

      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 it and hope for the best.

    4. Re:Must be designed secure - not "coded" by wiredlogic · · Score: 1

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

      --
      I am becoming gerund, destroyer of verbs.
    5. Re:Must be designed secure - not "coded" by cjonslashdot · · Score: 1

      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.

    6. Re:Must be designed secure - not "coded" by nightsky30 · · Score: 4, Insightful

      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.

    7. Re:Must be designed secure - not "coded" by ezdiy · · Score: 1

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

    8. Re:Must be designed secure - not "coded" by ralphsiegler · · Score: 1

      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.

    9. Re:Must be designed secure - not "coded" by Anonymous Coward · · Score: 0

      Google's bionic library is heavily OpenBSD libc based, and becoming more so.
      The OpenBSD project has a certified track record of hammering production-ready legacy systems into clean, simple and secure pieces of code. OpenBSD designed APIs are equally simple, robust, and secure.
      The OpenSSL security certified people have a certified track record of producing substandard code hack-by-hack and designing APIs that could have been better designed by a self-portraiting monkey.

    10. Re:Must be designed secure - not "coded" by gweihir · · Score: 1

      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 _decrease_ security by making it harder to get work done cleanly. At the same time, coding securely does nothing to create compliance. The whole idea is what happens when lawyers and other non-engineers try to ensure code is secure by creating "laws" that make it so.

      The only thing "secure" design patterns can give you is lower evaluation effort, but they can and do also create a false sense of security (and they can contain errors!) and hence are a very, very double-edged sword.

      --
      Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
    11. Re:Must be designed secure - not "coded" by gweihir · · Score: 1

      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 evaluation. The point is that any formalized argument is just a form of diversification and only helps if it is not more complicated than what it describes. Even then it is just as susceptible to having vulnerabilities itself.

      I do know that there are still people around that think formalizing everything will solve all security and reliability problems of software, but that argument has been debunked 25 years or so ago. The respective communities are still happily researching and getting happily ignored by anybody that needs real work done. At this time, the only thing that gives you a reasonable approximation at secure software, is software done by people with a high level of skill and experience in both coding and IT security. These are rare. From my observations, most IT security folks cannot code and most coders have no clue about IT security.

      --
      Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
    12. Re:Must be designed secure - not "coded" by arglebargle_xiv · · Score: 5, Insightful

      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.

    13. Re:Must be designed secure - not "coded" by cjonslashdot · · Score: 1

      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 perhaps the most fundamental aspect of any efforts to develop trustworthy systems, irrespective of the particular set of requirements whose satisfaction is necessary." Neumann is Principal Scientist at the Computer Science Laboratory of SRI International, Fellow of the AAAS, ACM, and IEEE, recipient of the ACM Outstanding Contribution Award in 1992, the Electronic Frontier Foundation Pioneer Award in 1996, and the ACM SIGSOFT Outstanding Contribution Award in 1997, an ACM National Lecturer for 16 months during 1969 and 1970, 1997 recipient of the Norbert Wiener Award for excellence in promoting socially responsible use of computing technology, SRI Fellow, and Honorary CISSP (Certified Information Systems Security Professional), awarded by the International Information Systems Security Certification Consortium -- (ISC)^2. I was therefore honored when he wrote the foreword for my book High-Assurance Design.

    14. Re:Must be designed secure - not "coded" by cjonslashdot · · Score: 1

      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 argument is merely the thought process of verifying those patterns and algorithms on paper before writing the code. And this can be done in an "agile" way by progressively refining and adding to the design: the focus is on the design, however - not the code.

    15. Re:Must be designed secure - not "coded" by gweihir · · Score: 1

      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.

      --
      Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
    16. Re:Must be designed secure - not "coded" by gweihir · · Score: 1

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

      I also disagree that good architecture is any more important than good design and good implementation. You need all three or you are vulnerable. Sure, coders often forget about architecture altogether and do only the minimal necessary design, and that usually results in an unmitigated failure, but a primary focus on architecture while design and/or implementation get neglected is just as bad. What you end up with is things that are general guidelines like architecture patterns (example: privilege separation), design techniques (like data-flow techniques such as data tagging) and implementation measures (such as checking assumptions like lengths and indexes). None of these are universal, and all have to be custom-tailored for the application and specific security requirements at hand.

      Security is hard and only really smart, experienced and dedicated people can get it right at this time. Some time in the (distant) future, there will be pre-made, dependable components that make things easier, but we are not there yet. OpenSSL is an attempt to create such a component and clearly shows this is a long and difficult process. Not that commercial libraries are any better. I tried some time ago to find out for a large customer what entropy gathering methods were used in one such library: Complete failure. I think they knew they had bad entropy gathering and were trying to hide that fact.

      --
      Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
    17. Re:Must be designed secure - not "coded" by cjonslashdot · · Score: 1

      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.

  2. I'm gonna FREAK! by Anonymous Coward · · Score: 2, Insightful

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

    1. Re:I'm gonna FREAK! by ralphsiegler · · Score: 5, Informative

      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/

    2. Re:I'm gonna FREAK! by ShanghaiBill · · Score: 2

      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.

    3. Re:I'm gonna FREAK! by ezdiy · · Score: 1

      A team with leadship in the realm of security

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

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

      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.

    4. Re:I'm gonna FREAK! by nightsky30 · · Score: 1

      THANK YOU! :)

    5. Re:I'm gonna FREAK! by Noryungi · · Score: 5, Informative

      Oh, really? A trainwreck?

      Explain this, then: [Source is here]

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

      --
      The right to offend is far more important than the right not to be offended. (Rowan Atkinson)
    6. Re:I'm gonna FREAK! by ralphsiegler · · Score: 1

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

    7. Re:I'm gonna FREAK! by gweihir · · Score: 1

      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.

      --
      Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
    8. Re:I'm gonna FREAK! by Anonymous Coward · · Score: 0

      LibreSSL has ripped out a ton of code, so yes, some issues will go away. But a lot of functionality has been lost too. And they've managed to add several _severe_ new vulnerabilities, such as failures to reinitialize the random pool resulting in duplicated and leaked keys.

      The code is still a hairball even with their modifications, but now it's a hairball hacked up by people who know it even less well than its regular authors.

    9. Re:I'm gonna FREAK! by ralphsiegler · · Score: 1

      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 and open manner

    10. Re:I'm gonna FREAK! by ralphsiegler · · Score: 1

      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
                          Affected code is not present.
                * CVE-2015-0208 - Segmentation fault for invalid PSS parameters
                          Affected code is not present.
                * CVE-2015-0293 - DoS via reachable assert in SSLv2 servers
                          Affected code is not present.
                * CVE-2015-0285 - Handshake with unseeded PRNG
                          Cannot happen by the design of the LibreSSL PRNG.

  3. Just... by Anonymous Coward · · Score: 0

    Bravo!

  4. Que 1000 posts fundraising for openbsd by rahvin112 · · Score: 3, Interesting

    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.

    1. Re:Que 1000 posts fundraising for openbsd by rubycodez · · Score: 3, Insightful

      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

    2. Re:Que 1000 posts fundraising for openbsd by Anonymous Coward · · Score: 0

      will not do as well as they have already done
      Unless they START with that code? ... hmm... maybe... hint hint...

    3. Re:Que 1000 posts fundraising for openbsd by Anonymous Coward · · Score: 0

      As far as I remember LibreSSL does not comply to several official security standards required by large business. The believe is that these standards make OpenSSL even less secure and are a waste of time, which even without detail knowledge on the matter isn't surprising since the NSA had its negative influence all over the place.

    4. Re:Que 1000 posts fundraising for openbsd by rahvin112 · · Score: 1

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

      Look at it this way, charities in the US are required by law to file public statements on how much of the donated money actually goes to support the charitable cause they are requesting support for. That information is missing in this case and it's rather important information. (I'm not claiming OBSD is violating the law, they are not in the US and not beholden to US charity laws). I believe 100% that leaving out the details of how the money will be spent is a lie through omission and that it's deliberate on their part. They should just be honest about it. It really grinds my gears when people lie through omission. It's more deceitful than bold faced lying in my opinion.

  5. Not the time... by x0ra · · Score: 4, Interesting

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

    1. Re:Not the time... by Anonymous Coward · · Score: 1, Interesting

      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.

    2. Re:Not the time... by Anonymous Coward · · Score: 0

      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

      No, it's an exercize in maintaining market share. Who's going to pay attention to libreSSL, no matter how superior it is, when openSSL has these shiny new, official-sounding audit results?

    3. Re:Not the time... by Anonymous Coward · · Score: 1

      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.

    4. Re:Not the time... by Anonymous Coward · · Score: 0

      Apparently the security research firms part of the NCCGroup are also responsible for the Truecrypt audits. Since the Linux Foundation is footing the bill for the audits, they would have full access to the code review and any testing results so I suppose they could release those to the public to allow to review the reviewers' work.

    5. Re:Not the time... by Anonymous Coward · · Score: 1

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

    6. Re:Not the time... by bill_mcgonigle · · Score: 1, 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 fixing OpenSSL and leaving portability intact is another valid strategy. That's far more work, but these guys were hired to do it (well,the first step of it) and somebody thinks it's valuable enough that they threw money at the problem.

      There's plenty of appreciation to be spread around here for all the teams working to secure our communications.

      --
      My God, it's Full of Source!
      OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
    7. Re:Not the time... by Anonymous Coward · · Score: 0

      Two words: momentum and FIPS. Not having to change your software as the underlying library is made more secure is a plus. Additionally, certain use cases require FIPS certification and OpenSSL is one of two options that are open source, and therefore usable without an additional fee.

    8. Re:Not the time... by Noryungi · · Score: 3, Interesting

      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:

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

      --
      The right to offend is far more important than the right not to be offended. (Rowan Atkinson)
    9. Re:Not the time... by zyche · · Score: 1

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

      [Citation needed]

  6. In Related News... by Bob9113 · · Score: 4, Funny

    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
    1. Re:In Related News... by Anonymous Coward · · Score: 0

      In related news, NCC Group today received 37 applications from extraordinary qualified candidates, all of whom -- by some extraordinary coincidence -- live in Langley, VA.

      Actually, they live in Fort Meade, Maryland: http://en.wikipedia.org/wiki/F...

      The CIA is in Langley, the NSA is Fort Meade.

  7. about time by Anonymous Coward · · Score: 0

    am i right??

  8. It is too much code to secure. by Anonymous Coward · · Score: 0

    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.

    1. Re:It is too much code to secure. by Anonymous Coward · · Score: 0

      The point isn't to secure it. The point is to give it a "stamp of approval" which can be used to push liability onto someone else. It's also so that NIST can insert backdoors and/or tell the NSA how to break it.

    2. Re:It is too much code to secure. by Marginal+Coward · · Score: 3, Informative

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

    3. Re:It is too much code to secure. by epine · · Score: 1

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

    4. Re:It is too much code to secure. by Marginal+Coward · · Score: 1

      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.

    5. Re:It is too much code to secure. by gweihir · · Score: 1

      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.
  9. For those that don't want to wait a year: by slashdice · · Score: 2

    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.
  10. Huh? by plcurechax · · Score: 1

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

    1. Re:Huh? by cant_get_a_good_nick · · Score: 1

      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?

    2. Re:Huh? by Anonymous Coward · · Score: 1

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

  11. OpenSSL Valhalla Rampage blog by thatseattleguy · · Score: 4, Insightful
    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, 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.

  12. Huzzah by Anonymous Coward · · Score: 0

    My heart bleeds to hear this...

  13. They will break it... by jtara · · Score: 1

    ... every which way to Sunday.

    1. Re:They will break it... by cbhacking · · Score: 1

      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.

      --
      There's no place I could be, since I've found Serenity...
  14. Great by jgotts · · Score: 1

    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.

  15. Did the NSA volunteer to do it by Anonymous Coward · · Score: 0

    and supply all the person power needed?

    1. Re:Did the NSA volunteer to do it by Anonymous Coward · · Score: 0

      Yes, but you won't be able to prove it.

  16. Product of its environment by QuietLagoon · · Score: 1
    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.

  17. mm too late .. we got libressl https://en.wikipedi by Anonymous Coward · · Score: 0

    https://en.wikipedia.org/wiki/LibreSSL

  18. No thanks by Anonymous Coward · · Score: 0

    After the sh*t I've read on opensslrampage.org I don't even want to touch anything from openSSL any more, "audited" or not. There's so much cruft and abject stupidity in there I can't trust it ever again.

    I feel dirty just knowing my Linux server has this crap infecting my web server and god knows what else. What a crapfest. The TLAs must be really pissed we finally are looking at this stuff, I guess at least that's a plus.

  19. Canaries by ThatsNotPudding · · Score: 1

    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?