Why OpenSSL vulnerabilities are not quite Heartbleed, but must be patched

About 10 years ago, we had the “Heartbleed” vulnerability in the OpenSSL cryptography library, which is used worldwide by many servers, desktops, and mobile devices. It was a bug and vulnerability so huge, Bruce Schneier, the internationally renowned security guru, famously said that on a scale of 1 to 10, the Heartbleed vulnerability was an 11.

Fast forward to 2022, OpenSSL is again in the spotlight, for as ignoble a reason as new vulnerabilities. Even though these 2 vulnerabilities are not as severe as the original Heartbleed, they must be patched, and we cannot take things lightly.

What exactly is Heartbleed vulnerability?

Commenting on Heartbleed vulnerability, Jonathan Knudsen, Head of Global Research, Synopsys Cybersecurity Research, said, “Bruce Schneier famously said that on a scale of 1 to 10 the Heartbleed vulnerability was an 11. He wasn’t wrong; Heartbleed was exposed by default on any software that used a vulnerable version of OpenSSL, and it was very easily exploitable by attackers to see cryptographic keys and passwords stored in server memory.”

“The two vulnerabilities just reported in OpenSSL are serious but not of the same magnitude. Vulnerable servers would need to be requesting client certificate authentication, which is not the norm, and vulnerable clients would need to connect to a malicious server, which is a commonplace attack vector anyhow. Nobody’s hair should be on fire about these two vulnerabilities, but they are serious and should be handled with speed and diligence.”

“If you don’t already know what open source components are in your software, consider implementing Software Composition Analysis (SCA) posthaste. Once you know which software has a vulnerable version of OpenSSL, you can update your software in priority order. Simultaneously, work with your vendors to get updates to the software you acquire.”

“For firms already managing software supply chain risk, this update of OpenSSL should be business as usual. Less prepared organizations should see this as an opportunity to start building software supply chain risk management into their processes,” Jonathan concludes.

How not to perform an incident response

Over the past days, there has been both anticipation and concern over a new vulnerability in OpenSSL. Details of this vulnerability were leaked on Oct 28th, and there was an expectation that this vulnerability would have a “Critical” rating. Along with the leak was a statement that a patch would be available on Nov 1st. We now know that this isn’t a critical vulnerability, but rather a “high” one. We also know that there are two vulnerabilities in the patch.

What happened?

Not surprisingly, a vulnerability in OpenSSL is going to gather industry concern and perhaps even media attention. With the initial rating of Critical, we saw media attention ramp up. This media attention realistically served two purposes. First, it focused attention within both the technical and non-technical ranks of organizations who might be using OpenSSL.

Second, it alerted the cyber-attacker community that there is something for them to focus their R&D efforts on – and that there might be a large target audience for such an attack.

Much of this chaos and increased software supply chain risk stems from the reality that publication of the existence of a vulnerability occurred before any patches were available. That then led to speculation, and some poor decision making by those attempting to protect their systems as part of their response to what they believed to be a major incident.

What should have happened?

It’s also crucially important not to downplay vulnerability management efforts, but perspective and pre-defined processes are key elements in incident response management.

In the early phases of the community reaction to what we know as CVE-2022-3602, I was recommending that firms perform a proactive scan of all of their software using tooling called Software Composition Analysis (SCA). SCA tooling scans the source code of an application and creates a Bill of Materials (BOM) for that application. If you don’t have access to the source code, major SCA vendors all have an option to scan binaries to create that BOM.

From an incident response perspective, you want to scan all the software your organization uses, regardless of its source or role. That includes commercial software, stuff that was freely downloaded, mobile applications and software like firmware that is included with hardware. Having a current, accurate and complete BOM for all software is a key to responding quickly to an incident like what we were expected from CVE-2022-3602.

How does a BOM benefit incident response?

Assuming you have a Bill of Materials (BOM) for all software, you then can query each BOM and find out if the vulnerable version of the software is referenced by or linked into an application. If it isn’t then there is nothing else to do. If it is, then there is some triage work to be done. To make things simple, for the pre-disclosed OpenSSL vulnerability, you could simply include in the list of applications to triage anything that references any version of OpenSSL.

We know that the impacted versions of CVE-2022-3602 are 3.0.0 to 3.0.6 which means that the triage list could be further filtered to only those versions of OpenSSL. With a list of apps, the next step is to identify where the patch for CVE-2022-3602 should come from.

While SCA tooling can help solve this problem to a degree, knowing what is being triaged is far more useful. For example, if you know you are triaging a web application running on a Linux VM, then the OpenSSL patch should come from the distro that created that Linux version. This paradigm holds true whether you’re dealing with VMs, containers, firmware, mobile applications, serverless functions, or any other deployment context.

Decreasing time to identification and remediation

Obviously not all potential providers of a patch will issue their patch at the same time, but when the disclosure of a vulnerability is held under embargo until patches are ready from a majority patch sources, everyone is playing on a level playing field. Tooling like SCA can greatly assist in reducing the time to identify impacted applications and deployments.

If you’ve heard about SBOM, it provides the same value as a BOM from an SCA tool. But as with SCA tooling you need to know how to use it for impact identification. Time to remediation will of course be subject to how long it takes to validate patches and then roll them out. By shortening the time to identification and focusing triage efforts to only systems and apps impacted by a vulnerability, remediation becomes quicker and more efficient.

Through the usage of SCA tooling, no longer are you sending emails to suppliers asking “Tell me if your firm is vulnerable to OpenSSL,” but instead you’re a proactive part of the solution and asking “I see that Awesome Acme Software may have exposure to CVE-2022-3602. Can you provide a timeline for patches and interim mitigation steps we can take?”

Tim Mackey is an open source software (OSS) expert and evangelist, and the Principal Security Strategist at Synopsys Cybersecurity Research Centre.