OpenSSL has a new critical bug. But its a secret-until next month.
Organizations have five days to prepare for what the OpenSSL Project on Oct. 26 described as a critical vulnerability in versions 3.0 and above of the nearly ubiquitously used cryptographic library for encrypting communications on the Internet.
On Tuesday, Nov. 1, the project will release a new version of OpenSSL (version 3.0.7) that will patch an as-yet-undisclosed flaw in current versions of the technology. The characteristics of the vulnerability and ease with which it can be exploited will determine the speed with which organizations will need to address the issue.
Potentially Huge Implications
Major operating system vendors, software publishers, email providers, and technology companies that have integrated OpenSSL into their products and services will likely have updated versions of their technologies timed for release with the OpenSSL Projects disclosure of the flaw next Tuesday. But that will still leave potentially millions of others – including federal agencies, private companies, service providers, network device manufacturers, and countless website operators – with a looming deadline to find and fix the vulnerability before threat actors begin to exploit it.
If the new vulnerability turns out to be another Heartbleed bug – the last critical vulnerability to impact OpenSSL – organizations and indeed the entire industry are going to be under the gun to address the issue as quickly as possible.
The Heartbleed vulnerability (CVE-2014-0160), disclosed in 2014, basically gave attackers a way to eavesdrop on Internet communications, steal data from services and users, to impersonate services, and do all this with little trace of their ever having done any of it. The bug existed in OpenSSL versions from March 2012 onward and affected a dizzying range of technologies, including widely used Web servers such as Nginx, Apache, and IIS; organizations such as Google, Akamai, CloudFlare, and Facebook; email and chat servers; network appliances from companies such as Cisco; and VPNs.
The disclosure of the bug triggered a frenzy of remedial activity across the industry and sparked concerns of major compromises. As Synopsys Heartbleed.com site noted, Apache and Nginx alone accounted for a market share of over 66% of active sites on the Internet at the time Heartbleed was disclosed.
Theres no telling, until Tuesday at least, if the new flaw will be anything like Heartbleed. But given the almost critical-infrastructure-like use of OpenSSL for encryption across the Internet, organizations would do well not to underestimate the threat, security experts said this week.
Security Orgs Should Brace for Impact
It is a bit difficult to speculate about the impact, but past experience has shown that OpenSSL doesnt use the label critical lightly, says Johannes Ullrich, dean of research at the SANS Institute.
OpenSSL itself defines a critical flaw as one that enables significant disclosure of the contents of server memory and potential user details, vulnerabilities that can be exploited easily and remotely to compromise server private keys.
Version 3.0, the current release of OpenSSL, is used in many current operating systems, such as Ubuntu 22.04 LTS and MacOS Mavericks and Ventura, Ullrich notes. Organizations can expect to receive Linux patches quickly and likely at the same time as the OpenSSL bulletin on Tuesday. But organizations should get ready now, finding out which systems use OpenSSL 3.0, Ullrich says. After Heartbleed, OpenSSL introduced these preannouncements of security patches, he says. They are supposed to help organizations prepare. So, use this time to find out what will need patching.
Brian Fox, co-founder and CTO at Sonatype, says that by the time the OpenSSL Project discloses the bug Tuesday, organizations need to identify if they are using a vulnerable version anywhere in their technology portfolio, which applications are using it, and how long it would take for them to remediate the issue.
Potential reach is always the most consequential piece of any major flaw, Fox notes. In this instance, the largest challenge with updating OpenSSL is that often this usage is embedded inside of other devices. In these instances, it can be hard to assess exposure without asking the upstream provider of the technology, he adds.
Anything that communicates with the Internet securely could potentially have OpenSSL built in to it. And its not just software that can be affected but hardware as well. The advance notice that the OpenSSL Project provided should give organizations time to prepare. Finding what pieces of software or devices is the first step. Organizations should do that now, and then patching or sourcing updates from the upstream vendors will follow, Fox says. All you can do at the moment is inventory.
An Entire Ecosystem Might Need to Update
A lot will also depend on how vendors of products with vulnerable versions of OpenSSL embedded in them respond to the disclosure. The OpenSSL Projects release of the new version on Tuesday is only the first step. An entire ecosystem of applications built with OpenSSL will also have to update their code, release their own updates, and organizations will need to apply them, says John Bambenek, principal threat hunter at Netenrich.
Ideally, organizations that have dealt with Heartbleed will have an idea of where their OpenSSL installs are and which of their vendor products will require an update as well. This is why software bills of materials can be important, Bambenek says. They can take this time to reach out and understand their suppliers and vendors plans for updates to make sure those updates are applied as well. One likely issue that organizations need to be prepared for is how to deal with end-of-life products for which updates are not available, he adds.
Mike Parkin, senior technical engineer at Vulcan Cyber, says that without evidence of exploit activity and associated indicators of compromise, it is best that organizations follow their normal change management process for when a known update is on the way. On the security side, its worth putting some additional focus on systems that might be affected if an exploit emerges before the new release drops, he advises.
Theres not enough information in OpenSSL Projects announcement to say how much work will be involved in the upgrade, but unless it requires updating certificates, the upgrade will probably be straightforward, Parkin predicts.
Also on Nov. 1, the OpenSSL project will release OpenSSL version 1.1.1s, which it described as a bug-fix release. Version 1.1.1, which it replaces, is not susceptible to the CVE that is being fixed in 3.0, the project noted.