Seems like INRIA is starting to do some formal checking of OpenSSL. Here's their page: http://prosecco.gforge.inria.fr/
Here's another OpenSSL flaw that was found with Coq, a formal prover: http://ccsinjection.lepidum.co.jp/blog/2014-06-05/CCS-Inject...
While this particular vulnerability in OpenSSL isn't nearly as bad as some of the other recent ones, it drives me crazy that we still have NULL pointer dereferences in something this critical. The worst part of this library is that the way it is organized makes it difficult to find these problems, or to use tools such as static analyzers to help. There are some amazing static analysis tools out there for C, but they are rendered useless by some of the hackery used in this library, such as their custom allocators. I don't mean to sound negative -- the OpenSSL team has done a great job making this library available in the first place -- but given how heavily this library is relied upon, better discipline is needed in this code base.
LibreSSL is a step in the right direction, and I commend the OpenBSD team for taking on this alternative. However, it's only a starting point. The entire approach of OpenSSL is dated, and it has not done a good job keeping up with our modern understanding of solid security engineering. The code base needs to be overhauled from the ground up with modern security and software development practices in mind. If ever there were a library that should be designed using formal proofs in software, it's this one. Even basic TDD with good code coverage would catch the majority of the bugs that have been discovered in OpenSSL over the past ten years.
</rant>
Kind of off-topic, but I wonder when they will release OpenSSL 1.0.2.
1.0.2 includes important fixes (e.g. support for ALPN which is mandatory in HTTP/2, adds support for cross-root certificate validation).
I'm unable to compile this on Win32 (I don't have any problems compiling older versions). I don't understand how the code could compile for anyone, maybe it's a platform specific issue. Take a look here on line 80:
https://github.com/openssl/openssl/blob/master/crypto/cversi...
The variable cflags isn't defined. I suspect it should be CFLAGS. I can make it compile locally by changing that, and it would make the code in the function consistent with the other code in the same file.
I thought C defines were case sensitive on all platforms. Anyone knows better than me?
https://github.com/openssl/openssl/compare/OpenSSL_1_0_1j......
And for future releases, it may be worthwhile to watch this URL to find unpatched vulnerabilities:
https://github.com/openssl/openssl/compare/OpenSSL_1_0_1k......
;)
Nothing on centos/epel yet.
Security advisory: https://mta.openssl.org/pipermail/openssl-announce/2015-Janu...
The optics of this advisory are bad, of course, but these are probably not operationally important bugs for most people:
* DTLS segmentation fault in dtls1_get_record (only impacts people who use DTLS, and is a null pointer deref, which usually isn't exploitable)
* DTLS memory leak in dtls1_buffer_record (same, and only exhausts memory)
* no-ssl3 configuration sets method to NULL (a non-standard build produces a null pointer crash in SSL3 negotiation)
* ECDHE silently downgrades to ECDH (this looks like a server can in an oddball situation lie about forward secrecy --- also, this only impacts OpenSSL clients, like curl)
* RSA silently downgrades to EXPORT_RSA (a server can sabotage the security of a session, which it can do in a variety of other ways anyways --- also, this only impacts OpenSSL clients, like curl)
* DH client certificates accepted without verification (breaks client authentication, which not many people rely on, but only affects servers that (a) do TLS client auth and (b) trust DH-key-issuing CAs, which are "extremely rare and hardly ever encountered")
* Certificate fingerprints can be modified (this one I actually wonder about the sev:lo on; it's low because it doesn't impact browsers, but certificate blacklists are common in enterprise software)
* Bignum squaring may produce incorrect results (this is just weird)