Mystery high severity bugs in OpenSSL to be patched on Tuesday


A new version of OpenSSL, the open-source software widely used to encrypt internet communications using SSL/TLS, is due to be released this Tuesday 1 March, fixing a number of security defects rated as "high severity."

If you want to know the specifics of what the vulnerabilities are then, tough. I can't help. The OpenSSL project team are playing their cards close to their chest.

In a online post, developer Mark J Cox made the brief announcement about the upcoming release of OpenSSL versions 1.0.2g and 1.0.1s.

The advisory went on to underline that anyone using OpenSSL should really be upgrading to the 1.0.2 version, as 1.0.1 will only be receiving security updates until the end of this year.

Openssl announcement

The OpenSSL project team would like to announce the forthcoming release of OpenSSL versions 1.0.2g, 1.0.1s.

These releases will be made available on 1st March 2016 between approximately 1300-1700 UTC. They will fix several security defects with maximum severity "high".

Please see the following page for further details of severity levels:

Please also note that, as per our previous announcements, support for 1.0.1 will end on 31st December 2016.

OpenSSL hasn't been having the best of times of late. Last month it told users to upgrade in order to fix vulnerabilities with its cryptography, and days later it was slagged off in a German government code review.

HeartbleedNone of which is as bad as the pickle OpenSSL found itself in 2014, when the notorious Heartbleed bug gave hackers a way to steal secret SSL keys, and spy upon the contents of supposedly "secure" communications, such as your credit card details when shared with an online store via HTTPS.

In the wake of Heartbleed, LibreSSL was proposed as a replacement for OpenSSL, and has gained fans because of the comparative clarity of its code, and that it has cut out a lot of the cruft which has plagued OpenSSL. But it would be true to say that LibreSSL has also suffered from its own fair share of vulnerability reports.

There is no indication that the new vulnerabilities will be anything like as serious as Heartbleed. For one thing, a flaw of that severity would almost certainly have merited a "critical" rating rather than "high", but they should still be taken seriously, and addressed promptly.

Tags: ,

Subscribe to the free GCHQ newsletter


Special offers & deals

  • Sticky Password Premium: Lifetime Subscription

    Sticky Password Premium: Lifetime Subscription

    Sticky Password protects your online identity by providing strong encrypted passwords for all your accounts, managed by a single master password known by you, and only you. Available for Mac, Windows, iOS, and Android. For a limited time, it's 80% off in our store.
  • IT Security & White Hat Hacking: CompTIA & Cisco Certifications

    IT Security & White Hat Hacking: CompTIA & Cisco Certifications

    Whether you're a beginner or mid-level professional, you'll want to take this comprehensive online course, to help you attain two industry-recognised certifications. You'll master mobile hacking, VPN technologies, penetration testing, and much more--giving you the knowledge you need to succeed in any IT workplace.

More deals...

Leave a reply

4 Comments on "Mystery high severity bugs in OpenSSL to be patched on Tuesday"

Notify of

Sort by:   newest | oldest | most voted
Poster Venti
February 25, 2016 5:15 pm

Just a couple remarks that might (and indeed should) concern administrators of certain distributions of Linux (this is a general concept, btw). This includes a CRITICAL POINT about the EOL of openssl 1.0.1 tree.

I mostly deal with Red Hat based distributions because some projects I work on also do. So:

First, CentOS 7.x has:

$ rpm -q openssl

Fedora 23 has:
$ rpm -q openssl

But then you have:
'The advisory went on to underline that anyone using OpenSSL should really be upgrading to the 1.0.2 version, as 1.0.1 will only be receiving security updates until the end of this year.'

The question will CentOS <= 7.x update ? Well besides the trees that have reached EOL (product life time is 10 years for CentOS and ~2 years for Fedora): likely not until CentOS 8. However, does that mean they are at risk as far as updates are concerned? No because they backport the security fixes. This means they merge the fixes (for security at least) from the relevant tree to the tree in question.

MOST IMPORTANTLY: DO NOT BLINDLY INSTALL A THIRD-PARTY openssl and ABSOLUTELY DO NOT COMPILE IT YOURSELF IN ATTEMPT TO 'FIX' IT! Not only will the packages (and this is important) you install (and even those not in RPMs) link into the system one (and don't even think about trying to remove the system openssl if any applications make use of it [or any package requires it] !!) and therefore make your supposed 'fix' irrelevant, it would only cause inconsistency in what links which openssl (what is linking to what version and also what what versions do you have installed where? Package managers have verification/consistency/etc. systems for a reason and it also allows for KNOWING what is there and what isn't; this is GOOD). As long as your distribution is still receiving updates it should be fine (backporting is a concept that is not exclusive to Red Hat distributions).

Poster Venti
February 25, 2016 5:22 pm

Actually, I was wrong in part: apparently some distributions do not considers backporting security (I should have known and perhaps did but I must say I'm disappointed). Shameful, yes, unfortunate also but is reality nonetheless.

Debian has a different policy; you have to explicitly install the backports:

Unbuntu is even worse (not surprising to me) where they have:
'Security Support for Backports

Unlike the packages released with Ubuntu, Backports do not come with any security support guarantee. The Ubuntu Security Team does not update packages in Backports. When a package which has been backported receives a security update, the Ubuntu Backporters will make a best-effort attempt to update the backport.'

Backporting is a general concept but apparently some distributions don't consider security as much as others. For Red Hat's policy (which is much, much better!) see:

February 25, 2016 7:44 pm

Oh bugger.

Every time YET ANOTHER bug is found in OpenSSL, I have to go through a whole thing to update Apache to use the new version, otherwise I won't pass the PCI DSS test.

Mark Jacobs
Mark Jacobs
February 26, 2016 10:48 am

Me too! And I have to wait until 3.00am to update Apache, because of the 24/7/365 nature of our servers. Current version is Apache 2.4.18 (using OpenSSL 1.0.2e) but that is dated 11th February. So, I'll wait for yet another newer version, 2.4.19. Jeez! It's never-ending! When are we going to get a stable, unhackable piece of encryption code? And what happens when hackers get their hands on real quantum computers and can crack any encryption with brute force instantly? Society, finances and the whole shebang will collapse! We should go back to abacuses but I bet they'd get hacked too! ;-)