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.
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: https://www.openssl.org/policies/secpolicy.html
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.
None 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.
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
openssl-1.0.1e-51.el7_2.2.x86_64
Fedora 23 has:
$ rpm -q openssl
openssl-1.0.2f-1.fc23.x86_64
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).
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:
http://backports.debian.org/Instructions/
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:
https://access.redhat.com/security/updates/backporting
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.
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! ;-)