As announced, OpenSSL releases a patch to a high severity vulnerability in the library.
For OpenSSL v1.0.2, this is the Denial of Service CVE.
Changes between 1.0.2 and 1.0.2a [19 Mar 2015]
*) ClientHello sigalgs DoS fix
If a client connects to an OpenSSL 1.0.2 server and renegotiates with an
invalid signature algorithms extension a NULL pointer dereference will
occur. This can be exploited in a DoS attack against the server.
This issue was was reported to OpenSSL by David Ramos of Stanford
University.
(CVE-2015-0291)
[Stephen Henson and Matt Caswell]
For OpenSSL v1.0.1 and v1.0.0 and v0.9.8, it’s this one (also a Denial of Service).
Changes between 1.0.1l and 1.0.1m [19 Mar 2015]
Changes between 1.0.0q and 1.0.0r [19 Mar 2015]
Changes between 0.9.8ze and 0.9.8zf [19 Mar 2015]
*) Segmentation fault in ASN1_TYPE_cmp fix
The function ASN1_TYPE_cmp will crash with an invalid read if an attempt is
made to compare ASN.1 boolean types. Since ASN1_TYPE_cmp is used to check
certificate signature algorithm consistency this can be used to crash any
certificate verification operation and exploited in a DoS attack. Any
application which performs certificate verification is vulnerable including
OpenSSL clients and servers which enable client authentication.
(CVE-2015-0286)
[Stephen Henson]
OpenSSL 1.0.1 release notes – OpenSSL 1.0.0 release notes – OpenSSL 0.9.8
So it’s upgrade time again, although the impacted systems could be a relatively small subset of your servers. However, if you’re vulnerable, you may want to give this some priority.
The patch (the actual changed code) to the v1.0.2 vulnerability is like this.
Full commit is here: 34e3edbf3a10953cb407288101fd56a629af22f9.
The 0.9.8, 1.0.0 and 1.0.1 patches are much smaller, but have the same DoS effect.
Full commit is here: 02758836731658381580e282ff403ba07d87b2f8.
The feared Denial of Service attack is, unfortunately, not limited to OpenSSL v1.0.2, as was anticipated. It affects v1.0.1 and v1.0.0 and v0.9.8 as well.
Responsible Disclosure
Announcing these kind of patches in advance, even without publishing the details of the patch or the CVE, will surely attract the attention of some bad guys as well. You can be sure they were awaiting the release and are now working on ways to make use of it.
Having said that, this kind of responsible disclosure is of the best kind: everyone knows in advance to reserve (human) resources in order to deal with the problem. OpenSSL did it right for 90%. The remaining 10% would have been deserved if they had bothered to securely and discretely update LibreSSL of this issue, so they could prepare patches on their end as well.
Update: OpenSSL did inform the LibreSSL team of this vulnerability. A well-deserved 100% score for this responsibly disclosed vulnerability.
How to patch
As usual with OpenSSL patches, it’s a 2-step fix. First, update the library on your OS.
$ yum update openssl
or
$ apt-get update $ apt-get install openssl
Then, find all services that depend on the OpenSSL libraries, and restart them.
$ lsof | grep libssl | awk '{print $1}' | sort | uniq
Since the attack is a remote DoS, you should restart the public facing services as soon as possible. The internal services could be done at a later, more convenient, time.
Note: local system users may still be able to exploit those internal services, but it’s another requirement in the whole exploit. Short-term, attackers will aim for the low hanging fruit: externally available services.
Long-term Library Fixes
Every time something like this happens, either in OpenSSL or in glibc, I keep thinking about mapping these library dependencies in config management.
Maybe some day, I’ll make a proof of concept for this. And some day, it’ll save me a few hours of work, for every emergency patch that comes out. Some day.