1. 21

  2. 10

    Hopefully LibreSSL is safe - but you cannot be sure due to a lack of information: http://marc.info/?l=openbsd-misc&m=142654095813320&w=2

    1. 10

      It will be interesting to see as time goes on, how many issues in openssl end up being already fixed and/or non-issues in libressl and/or boringssl. Maybe a few incidents where that is the case will finally get people to moving to something better.

      1. 9

        I’ve always wondered what the OpenSSL folks thought of being forked. Question answered.

        1. 5

          Looks like there has been some progress: link to my other comment on email to misc@openbsd.org

        2. 6

          Why does anyone trust these people anymore?

          1. 8

            Infrastructure Lock. Downtime for upgrades are dangerous, doubly so if you are switching underlying things like SSL. Also in a lot of entities eyes, there is nothing to replace OpenSSL currently. LibreSSL is there, but said entities aren’t going to jump that ship until it has been “vetted”.

            1. 6

              I’d imagine for many of those entities the lack of FIPS 140 support will be a dealbreaker for LibreSSL. This isn’t a bad thing, by the way: look at all the BS OpenBSD would have to do to support FIPS 140 which is nothing more than security theatre anyhow.

              1. 4

                I agree, of course, on all of that. The further implication is that there will, soon, be a much more obvious choice between compliance and security. Of course there has always been one, but soon it will be far more difficult for anyone to block out that knowledge. When that comes to a head, it should be interesting…

          2. 3

            People in the know (Mark Cox, RedHat security team) seem to think it won’t be as bad as some previous issues and the high severity vulnerability only affects the 1.0.2 branch only.

            1. 3

              So what will it take to get a OpenSSL with a C API written in a safe language? Is Rust our best hope as things stand right now?

              1. 3

                Wasn’t it already demonstrated that a “safe” language wouldn’t have prevented Heartbleed?

                1. 10

                  Depends on your definition of “safe”. Considering it is accessing a buffer outside a correct bounds, and this information can be encoded into an expressive type system, then I’m not sure how it wouldn’t have prevented it. That is not to say that a safe language prevents all bugs, of course.

                  According to wikipedia:

                  The affected versions of OpenSSL allocate a memory buffer for the message to be returned based on the length field in the requesting message, without regard to the actual size of that message’s payload. Because of this failure to do proper bounds checking, the message returned consists of the payload, possibly followed by whatever else happened to be in the allocated memory buffer.

                  But even if it wouldn’t fix Heartbleed, Heartbleed is hardly the first or last hole to hit OpenSSL as a result of using C or C++. It’s no secret that these languages are inherently unsafe and difficult to audit.

                  Perusing the OpenSSL vulnerabilities list, I would classify the following as the result of using an unsafe language:

                  1. CVE-2014-3571: 8th January 2015 A carefully crafted DTLS message can cause a segmentation fault in OpenSSL due to a NULL pointer dereference. This could lead to a Denial Of Service attack.
                  2. CVE-2014-3569: 21st October 2014 When openssl is built with the no-ssl3 option and a SSL v3 ClientHello is received the ssl method would be set to NULL which could later result in a NULL pointer dereference.
                  3. CVE-2014-3513: 15th October 2014 A flaw in the DTLS SRTP extension parsing code allows an attacker, who sends a carefully crafted handshake message, to cause OpenSSL to fail to free up to 64k of memory causing a memory leak. This could be exploited in a Denial Of Service attack. This issue affects OpenSSL 1.0.1 server implementations for both SSL/TLS and DTLS regardless of whether SRTP is used or configured. Implementations of OpenSSL that have been compiled with OPENSSL_NO_SRTP defined are not affected.
                  4. CVE-2014-3567: 15th October 2014 When an OpenSSL SSL/TLS/DTLS server receives a session ticket the integrity of that ticket is first verified. In the event of a session ticket integrity check failing, OpenSSL will fail to free memory causing a memory leak. By sending a large number of invalid session tickets an attacker could exploit this issue in a Denial Of Service attack.
                  5. CVE-2014-5139: 6th August 2014 A crash was found affecting SRP ciphersuites used in a Server Hello message. The issue affects OpenSSL clients and allows a malicious server to crash the client with a null pointer dereference (read) by specifying an SRP ciphersuite even though it was not properly negotiated with the client. This could lead to a Denial of Service.
                  6. CVE-2014-3509: 6th August 2014 A race condition was found in ssl_parse_serverhello_tlsext. If a multithreaded client connects to a malicious server using a resumed session and the server sends an ec point format extension, it could write up to 255 bytes to freed memory.
                  7. CVE-2014-3505: 6th August 2014 A Double Free was found when processing DTLS packets. An attacker can force an error condition which causes openssl to crash whilst processing DTLS packets due to memory being freed twice. This could lead to a Denial of Service attack.
                  8. CVE-2014-3507: 6th August 2014 A DTLS memory leak from zero-length fragments was found. By sending carefully crafted DTLS packets an attacker could cause OpenSSL to leak memory. This could lead to a Denial of Service attack.
                  9. CVE-2014-3512: 6th August 2014 A SRP buffer overrun was found. A malicious client or server can send invalid SRP parameters and overrun an internal buffer. Only applications which are explicitly set up for SRP use are affected.
                  10. CVE-2014-0221: 5th June 2014 By sending an invalid DTLS handshake to an OpenSSL DTLS client the code can be made to recurse eventually crashing in a DoS attack. Only applications using OpenSSL as a DTLS client are affected.
                  11. CVE-2014-0195: 5th June 2014 A buffer overrun attack can be triggered by sending invalid DTLS fragments to an OpenSSL DTLS client or server. This is potentially exploitable to run arbitrary code on a vulnerable client or server. Only applications using OpenSSL as a DTLS client or server affected.

                  My hand is getting tired though…

                    1. 2

                      The post by Tony Arcieri claims it’s not Heartbleed, but a security hole in its own right. But this demonstrates that the semantics of Rust are not “safe” enough. Not that a “safe” language would not prevent Heartbleed (or @tedu’s bug).

                      And the issue @tedu is pointing out should be clear: it’s not using construction to create safety. It’s an optimisation, using a mutable buffer. Mutability being a known cause of many bugs in a sufficiently complicated program. If the code was structured in such a way that construction guaranteed correctness then this particular bug would not be present.

                      I think people really undervalue the benefits of using construction as a tool for safety.

                      One thing that I would love to know is: it’s clear that using a safer language prevents various forms of errors, buffer overflows, some kinds of memory leaks, using freed memory, etc. But does using a safer language reduce the total bug count or do we introduce a new class of bugs to replace the ones we saved? My guess is that the total bug count is reduced. For one, we remove all those unsafe bugs. But two, while we introduce a new set of bugs, I believe the way we have to construct code in a safe language is probably going to remove bugs that are not directly related to the safe language bugs. For example, if I have to use construction-for-safety everywhere, it’s quite possible I will remove a whole bunch of other bugs that are not directly related to memory safety. tedu’s bug being an example. I have no evidence for this, I am aware of that, nor am I saying that a safe language makes programs bug free. My experience has been using a more restrictive language results in fewer total bugs, however, both logic bugs and memory bugs.