Today the OpenSSL project has released new versions for the 0.9.8, 1.0.0, 1.0.1 and 1.0.2 branches of the library. My current employer Coresec Systems AB has allowed me to spend some time preparing for the release and documenting a bit the issues and possible work arounds.
In this blogpost I will release some of the insights on what I have found about these issues, the risks they carry and, when possible, how they may be worked around if patching is impossible for you. This information is still provisional pending a full code analysis of the issues. Anyways, patched versions are better than any workaround to mitigate the problem so upgrading is not only recommended but a better solution.
So the first big issue is ClientHello sigalgs DoS fix. They say this is caused by renegotiation which in theory most server reject outwards, but it may also be triggered during the initial handshake too. Sadly there is no workaround so if you have SSL 1.0.2 you should upgrade to 1.0.2a
The second one is the raising of the FREAK exploit to High severity which makes sense.
The third one is the Multiblock corrupted pointer fix this seems to be affecting the handling of AES encryptions and can be worked around by disabling AESNI support in SSL which, at least for some utils, can be done by setting the environment variable OPENSSL_ia32cap=”~0x200000200000000″
The fourth one is the Segmentation fault in DTLSv1_listen fix this one seems to be fixable by making sure DTLS support is enabled for all the versions a server can support, though there may be more meat to it. Of course you can still safely disable SSLv2 and SSLv3 as DTLS didn’t even exist for those.
Fourth there are many vulenrabilities involving DoS during certificate validation, the most worrying of which is Segmentation fault in ASN1_TYPE_cmp fix sadly these affect servers validating client certificates and use of booleans in ASN.1 doesn’t seems to be illegal input (unlike many other problems which have at least suspicious inputs). There is no workaround on this one and the issue may have a bigger impact than you believe. Webservers using smartcard authentication systems like the spanish DNI-E may be affected as these involve verifying a client side certificate, So may be other certificate based login systems like Cacert and maybe even banking systems using such features. This also may affect some VPN providers using these like openVPN, VoIP software like mumble and even RADIUS servers when EAP-TLS is used (and the worst thing in this last case is that the attacker could just hide a small wireless device with a large battery to bring down the wireless network).
Then we have the DoS via reachable assert in SSLv2 servers fix this can probably be worked around by disabling SSLv2 support in the server which you should have done anyways.
The last but not least vulnerability affecting SSL client and servers directly is Handshake with unseeded PRNG fix the truth is that this one is a badie, if the PRNG is not seeded chances are that many cryptographic secrets can be figured out and information leaked but fortunately it seems to have many preconditions to trigger (they give the example of using PSK authentication which is very rare on servers as it requires both sides knowing a shared key). This may be worked around by diabling such algorithms on your server, and most likely won’t affect you if you just do the classical RSA (or ECDHE-RSA) exchanges used on certificate based systems.
This covers the problems which could affect clients using OpenSSL for SSL connections there are other vulnerabilities fixed like ASN.1 structure reuse memory corruption fix, PKCS7 NULL pointer dereferences fix or X509_to_X509_REQ NULL pointer deref fix but most chances are on these not affecting you unless your program uses openssl for other cryptographic features aside from SSL connections.
To conclude this report I should inform that sadly Gentoo Hardened seems unable to mitigate any of the issues presented here (keep in mind that most of the hardening aims at making exploiting issues harder but can’t mask the issues themselves) so if you are using Gentoo you are recommended to upgrade. You can keep track of this issue on the GLSA or the associated Gentoo bug report.
That’s it. Again thanks a lot to Coresec Systems AB for allowing me to invest some time in researching this release. For more info on what we do and how they can help you improve your security you may want to check their webpage.
EDIT:
I made a deeper analysis on the ASN Boolean segfault, basically the attacker can get control over the last byte of a group of 4 and make it either 00 or FF. On 32 bit machines this is bound to end on a SEGFAULT as the dereference will be either at NULL or at NULL+255 which is usually on the same invalid page. On 64 bit machines there will be 4 more bytes of the dereferenced pointer which will be undetermined and could be controlled by the attacker allowing control over the highest or lowest half of the memory aside from the extra byte.
This attack could lead to a data disclosure in rare cases where the attacker can control whether the memory in a pointed area matches against the memory in the area pointed by the other cert to be compared against. I believe the attack quite unlikely and I couldn’t figure a PoC out of it but it’s better to be ready in case it arises.