The security community has been poring over an apparently critical vulnerability in the OpenSSL open source cryptography library, which is set to be patched on the afternoon of Tuesday 1 November, but about which few further details have yet been forthcoming.
The team behind the OpenSSL project – which underlies the majority of encryption across the internet – trailed the upcoming patch to version 3.0.7 in an advisory posted on Tuesday 25 October. “OpenSSL 3.0.7 is a security-fix release. The highest severity issue fixed in this release is critical,” the team said.
The patching of any vulnerability in OpenSSL is a noteworthy moment – the last such release took place in 2016. Furthermore, this is the first critical vulnerability found in the component since the project starting tracking such things in the wake of CVE-2014-0160, more commonly known as Heartbleed.
Heartbleed is a coding flaw that could allow an attacker to repeatedly get at unecrypted data from the memory of systems using vulnerable versions of OpenSSL, and it shook the industry to its foundations when it was made public in April 2014.
For many, the discovery of a new critical vulnerability in OpenSSL naturally raises unpleasant memories of Heartbleed. For others, the widespread use of OpenSSL across the internet prompts comparisons with Log4Shell, one of the most impactful open source bugs ever discovered, the ramifications of which are still being felt nearly 12 months after it was first uncovered.
But while this new flaw is yet to prove as severe or possibly moreso than either of these, as Mattias Gees, container product lead at Venafi, explained: “Heartbleed had a significant impact on all operations teams worldwide, [but] since then IT infrastructure has become 10 times more complicated.
“When Heartbleed was discovered, the majority of IT organisations were using dedicated hardware or virtual machines [VMs]. But now we are in the cloud-native era, which has created advanced containers and serverless architectures,” said Gees.
“The attack vector has become a lot larger, and rather than just having to examine their VMs, organisations need to start preparing to patch all their container images in response to this announcement.”
But, he added, there was some good news in that Log4Shell may have triggered a lot of security teams to audit their open source dependencies, potentially putting them in a better position to be able to deal with whatever is about to come around the corner.
If they have done this, said Gees: “These steps will help teams to quickly roll out a targeted fix on their infrastructure. Software Bill of Materials [SBOMs] of all container images are a great start to gaining those insights into the dependencies in your applications and infrastructure.”
That the OpenSSL team has given security teams advanced warning is also somewhat of an unusual step, but may be a small mercy in that they have given people time to clear the decks in advance and ensure they won’t be blindsided by it.
Paul Baird, chief technical security officer at Qualys, said that OpenSSL defines a critical update as one that affects common configurations and are likely to be exploitable in such a way that they allow for significant disclosure of the contents of server memory and reveal user details; can be easily exploited remotely to compromise server private keys; or which could likely lead to remote code execution (RCE).
“This is therefore going to be an issue that everyone will have to patch pretty much immediately on release of the updated versions of OpenSSL. From a planning and prioritisation point of view, this will be what many security professionals spend their time on next week,” said Baird.
“Best practices here would be to know all your OpenSSL implementations, what versions they are at, and prioritise your update plans accordingly. With something like this, being forewarned is forearmed, as I would expect there to be a lot of interest in the details of any issue and any proof of concept code releases, both from security professionals and from bad actors.”
What is known is that the incoming vulnerability only affects 3.0.x versions of OpenSSL, which means anybody still running 1.1.1 versions ought to be safe, and will enable security teams to dismiss some sections of their infrastructure right away. This may mitigate the impact a little.
Michael Clark, Sysdig director of threat research, and his team have probed some of the most common container base images, including RHEL, Alpine and Debian, to find out if they had OpenSSL by default and, if not, what version you would get if you went and installed OpenSSL from the package manager.
They found that neither RHEL/ubi8, Alpine or Debian contain OpenSSL by default, nor does Ubuntu, while others such as Nginx and MySQL are still on 1.1.1. Node.js stands out as being on 3.0.5.
“The good news is that the OS container images don’t tend to have OpenSSL installed by default. It’s not surprising as it is good form to keep container images as minimal as possible. Most of the default package manager installs also don’t use OpenSSL 3.0.x,” said Clark.
“Application images are much more likely to have a version of OpenSSL installed. There is also a lot of version drift with applications and OpenSSL versions.”
Chris Dobrec, vice-president of product and industry solutions at Armis, added that OpenSSL does provide a command line utility that can be queried to find out what version of OpenSSL is running, but noted that it was still important to search for non-standard installations that may be in use elsewhere.
