DigiCert Blog

OpenSSL Patches Five Security Vulnerabilities

The vulnerabilities identified in OpenSSL do not affect SSL Certificates; system admins should patch their OpenSSL framework as soon as possible

Earlier this morning, the OpenSSL project team released two security patches—1.0.2h and 1.0.1t—for five security vulnerabilities discovered in OpenSSL. These two new patches fix one “high” severity and four “low” severity vulnerabilities.

None of these bugs affect SSL Certificates. No actions related to SSL Certificate management are required.

High Severity Vulnerabilities

Memory corruption in the ASN.1 encoder (CVE-2016-2108)

The OpenSSL Security advisory reported two high severity vulnerabilities. However, the first high severity vulnerability listed, Memory Corruption in the ASN.1 encoder (CVE-2016-2108), is a combination of two bugs that individually do not impact security.

The first bug in the combination was fixed on April 18, 2015. For those running a version of OpenSSL prior to April 2015, the best course of action is as follows:

  • OpenSSL 1.0.2 users should upgrade to version 1.0.2c
  • OpenSSL 1.0.1 users should upgrade to version 1.0.1o

The second bug in the combination, “negative zero” memory, is about the mishandling of universal tags. The best course of action for this bug according to the OpenSSL Security Advisory is as follows:

The fix for the ‘negative zero’ memory corruption bug can be identified by commits:

  • 3661bb4e7934668bd99ca777ea8b30eedfafa871 (1.0.2)
  • 32d3b0f52f77ce86d53f38685336668d47c5bdfe (1.0.1)”

Padding oracle in AES-NI CBC MAC check (CVE-2016-2107)

This high severity vulnerability was ushered in as part of the Lucky 13 padding attack (CV#-2913-0169). The padding oracle vulnerability can allow MITM attacker to use a padding oracle based attack to decrypt traffic. However, the connection must use AES CBC cipher and the server must support AES-NI.

The fix for the padding oracle vulnerability is as follows:

  • OpenSSL 1.0.2 users should upgrade to version 1.0.2h
  • OpenSSL 1.0.1 users should upgrade to version 1.0.1t

Source code for both OpenSSL patches is available at OpenSSL Cryptography and SSL/TLS Toolkit.

For a full list of vulnerabilities, see the OpenSSL Security Advisory [3rd May 2016].

Low Severity Vulnerability

The “low” severity vulnerabilities affect both instances of OpenSSL: 1.0.2 and 1.0.1.

  • EVP_EncodeUpdate overflow (CVE-2016-2105)
  • EVP_EncryptUpdate overflow (CVE-2016-2106)
  • 1 BIO excessive memory allocation (CVE-2016-2109)
  • EBCDIC overread (CVE-2016-2176)

System admins should update their instance(s) of OpenSSL:

  • OpenSSL 1.0.2 users should upgrade to version 1.0.2h
  • OpenSSL 1.0.1 users should upgrade to version 1.0.1t

Source code for both OpenSSL patches is available at OpenSSL Cryptography and SSL/TLS Toolkit.

For a full list of vulnerabilities, see the OpenSSL Security Advisory [3rd May 2016].

Plan to Upgrade to OpenSSL 1.0.2

Don’t forget that OpenSSL will stop supporting OpenSSL 1.0.1 on December 31, 2016. If you are running an instance of OpenSSL 1.0.1, make plans to upgrade to the latest version of OpenSSL 1.0.2 today.

Keeping Your OpenSSL Secure

The OpenSSL community wants to keep your supported OpenSSL release secure. That’s why devoted researchers and security experts working with other online providers and open source developers work hard to discover and remedy vulnerabilities in the OpenSSL framework before attackers find the vulnerabilities and exploit them.

Although moans, groans, and occasional curses may be heard each time new patches must be applied, preventative maintenance is a much better strategy than trying to fix things after something goes wrong, i.e., a security breach. Take the time to apply the latest patches and keep your OpenSSL code secure.

Share on Facebook0Share on Google+0Tweet about this on TwitterShare on LinkedIn23

About Jason Sabin

DigiCert's Chief Security Officer, Jason Sabin, develops innovative products and features to simplify SAAS-based digital certificate management. Previously he oversaw Novell’s Security Review Board and built their first pen testing teams. He has filed over 50 patents, earning him the “Utah Genius” award.