New high severity OpenSSL vulnerability revealed. It’s time to upgrade

HTTPSEarlier this week I warned that details of a high severity bug in OpenSSL, the open-source software widely used to encrypt many of the internet’s communications, was to be revealed today.

The average internet user probably only realises that their communications are being encrypted when they visit a website using HTTPS and see the little green padlock in their browser’s URL bar. But the truth is that many apps also use the OpenSSL code library to communicate securely via the net.

So more details of the flaw, and the fix, were eagerly awaited by many.

Sure enough, right on time, an advisory was posted to the OpenSSL website.

Sign up to our free newsletter.
Security news, advice, and tips.

OpenSSL advisory

Plenty of people are trying to reach that site right now, for understandable reasons, and as a consequence many folks are finding it hard to get through.

For your benefit, therefore, I’ve duplicated the meat of the advisory below:

Alternative chains certificate forgery (CVE-2015-1793)

Severity: High

During certificate verification, OpenSSL (starting from version 1.0.1n and 1.0.2b) will attempt to find an alternative certificate chain if the first attempt to build such a chain fails. An error in the implementation of this logic can mean that an attacker could cause certain checks on untrusted certificates to be bypassed, such as the CA flag, enabling them to use a valid leaf certificate to act as a CA and “issue” an invalid certificate.

This issue will impact any application that verifies certificates including SSL/TLS/DTLS clients and SSL/TLS/DTLS servers using client authentication.

This issue affects OpenSSL versions 1.0.2c, 1.0.2b, 1.0.1n and 1.0.1o.

OpenSSL 1.0.2b/1.0.2c users should upgrade to 1.0.2d
OpenSSL 1.0.1n/1.0.1o users should upgrade to 1.0.1p

This issue was reported to OpenSSL on 24th June 2015 by Adam Langley/David Benjamin (Google/BoringSSL). The fix was developed by the BoringSSL project.

As ThreatPost reports, the bug only affects OpenSSL 1.0.1 and 1.0.2, which were released in June.

Obviously, it’s not a good idea if an attacker is able to bypass checks to trick systems into thinking that an untrusted certificate is really trusted, or to act as a bogus certificate authority and issue invalid certificates.

Fortunately Rich Salz, a member of the OpenSSL development team, says that there are no reports of the vulnerability being publicly exploited.

If you’re a regular computer user, then there’s nothing really for you to do – other than to wait to hear if your browser and operating system have received appropriate patches.

If you are responsible for running your own servers or develop apps that rely upon secure OpenSSL communications then you should look into applying the fix at the earliest opportunity.

OpenSSL’s developers also took the opportunity to remind the community that support for version 1.0.0 and 0.9.8 of OpenSSL will cease on 31st December 2015.

In other words, there won’t be any further security updates for those particular versions in 2016 and beyond.

In a nutshell: the clock is ticking, get a move on.

Graham Cluley is an award-winning keynote speaker who has given presentations around the world about cybersecurity, hackers, and online privacy. A veteran of the computer security industry since the early 1990s, he wrote the first ever version of Dr Solomon's Anti-Virus Toolkit for Windows, makes regular media appearances, and is the co-host of the popular "Smashing Security" podcast. Follow him on Twitter, Mastodon, Threads, Bluesky, or drop him an email.

One comment on “New high severity OpenSSL vulnerability revealed. It’s time to upgrade”

  1. Tim Mc.

    It's worth noting that this particular issue is client-side only. While updating servers is always prudent, there should not be the same rush to patch that was required with Heartbleed.

What do you think? Leave a comment

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.