OpenSSL vulnerabilities: Serious, but not weapons of mass digital destruction

It sounded like an impending digital disaster. But a couple of vulnerabilities announced Oct. 26 by the OpenSSL Project — labeled “critical” at the time — in the widely used OpenSSL cryptographic library turned out not to be Heartbleed 2.0, generating sighs of moderate relief after a week of frantic speculation.

That doesn’t mean they weren’t serious. If a program that encrypts internet communications is compromised, the possibilities are grim. Criminal hackers could exploit them to collect data that is supposed to be secure, like passwords, credit card numbers, Social Security numbers, and more.

But these vulnerabilities, while they needed to be fixed, were not weapons of mass digital destruction, in large measure because they affect only more recent versions — 3.0 and above — of OpenSSL, and a majority of users are still using version 1.1.1, which doesn’t contain the vulnerabilities.

The last time the OpenSSL Project announced a critical vulnerability was in 2014, and the bug, which came to be known as Heartbleed, was one of the most catastrophic in internet history. Joseph Steinberg, a cybersecurity columnist, wrote in Forbes at the time, “Some might argue that it is the worst vulnerability found (at least in terms of its potential impact) since commercial traffic began to flow on the internet.”

That’s because, as a post in Dark Reading put it, “[Heartbleed] 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.”

And it’s why since before that event software security experts have been urging everybody who uses open source software components — which is everybody everywhere — to keep track of them and keep them up-to-date.

While open source has many advantages (hence its universal use), it can put users at risk if they fail to install patches to fix bugs or defects in a component because they don’t know they’re using it.

The OpenSSL Project’s announcement was the latest high-profile reminder of that risk. But by the time the update fixing the defects (version 3.0.7) was released on Nov. 1, they had been downgraded to “high severity” — still significant but nowhere near as dangerous as the initial hype suggested.

Mitigating factors

That was due to several significant mitigating factors.

First, it’s unusual, and unusually good, to get notice of vulnerabilities before the details of them become public, and for a patch to be available the day they become public. Often vulnerabilities aren’t discovered until weeks, months, or even years after hackers have begun exploiting them. Criminals began secretly exploiting Heartbleed in 2012 but it wasn’t publicly known until 2014.

Second, the use of OpenSSL is not as universal as it was a decade ago. While there are still many thousands of users, internet security firm Censys reported that as of Oct. 30, only 7,062 hosts were running a susceptible version of OpenSSL, with a majority of those in the U.S. (2,321), and fewer than 700 in Germany, Japan, China, Czechia, the U.K., France, Russia, Canada, and the Netherlands.

Michael White, technical director and principal architect with the Synopsys Software Integrity Group, noted that “there is much more diversity in the choice of SSL libraries following Heartbleed. When Heartbleed occurred, OpenSSL was the leading library but now the world has several other lightweight options — for example Boring SSL and LibreSSL — which seek to mitigate risk via transparency and simplification.”

Beyond that, many users are still using earlier versions of OpenSSL that don’t have the vulnerabilities found in version 3. While the OpenSSL Project announced that its Nov. 1 updates also included an update for version 1.1.1, that is simply a bug fix, not a security fix.

“These vulnerabilities impacted only the version 3.0 stream of development,” said Tim Mackey, principal security strategist, Synopsys Cybersecurity Research Center, “and the initial release of version 3.0 was in September 2021. Version 3.0 is very early in its lifecycle, and that’s a key contributor to why these two vulnerabilities have a lower impact,” he said, adding that the 1.1 versions will remain fully supported for 10 more months, until September 2023.

Much smaller attack surface

All of which means the “attack surface” this time is far smaller than it was for Heartbleed.

Finally, experts agree with OpenSSL that while the vulnerabilities just patched are serious, they don’t rise to the “critical” level.

The most likely attacks from exploiting them would be denial of service (DoS), in which attackers are able to flood a website with so much junk traffic that it crashes, or remote code execution (RCE), in which the vulnerability allows an attacker to execute malicious code on a computer remotely, which could result in the attacker taking control of the machine.

But the OpenSSL Project, in a Nov. 1 blog post, reported that, “We are not aware of any working exploit that could lead to remote code execution, and we have no evidence of these issues being exploited as of the time of release of this post.”

That doesn’t mean those using versions 3.0 and above should relax. The Sophos Naked Security blog declared “We strongly recommend that you update, with as much urgency as you can muster.” And OpenSSL itself “still considers these issues to be serious vulnerabilities and affected users are encouraged to upgrade as soon as possible.”

Overall, the event should serve as an illustration of what needs to be done to use open source software safely.

To start, situations like this are more likely with open source because updates aren’t “pushed” to users, as is the case with commercial software. Users have to be aware that updates are available for a product they’re using and then “pull” them from a repository. Obviously, they are unlikely to do so if they don’t know they need to.

Get the right tools

And while individual users likely don’t have the capacity to track every open source component of the software they’re using, at the oganizational level it can be done with an automated tool called software composition analysis (SCA).

That tool, which will help find open source components and identify any known vulnerabilities and potential licensing conflicts, can also help compile a software Bill of Materials (SBOM), something that is headed toward becoming a mandatory element of all software products. President Biden’s May 2021 executive order on improving the nation’s cybersecurity calls for it to be required with any software product purchased by federal agencies.

As Mackey put it, “The flaw in OpenSSL is an example of why SCA is so fundamentally important for any AppSec and InfoSec team. The results of SCA will show exactly where a component is used, and which version is in use. This allows response teams to respond quickly to any new vulnerability independent of its severity, version, and where the patch needs to come from.”

Mackey also noted that in the case of OpenSSL, “there are many thousands of forks — also known as branches — of code. Each may have a different set of requirements for each compilation.”

The Dark Reading post noted that while bigger tech players that have long integrated OpenSSL into their products and services were likely ready for the updates, that still left “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.”

And without an automated tool like SCA to help find every instance of OpenSSL, that is a long and complicated task because individual software components can be buried deep within products, services, or devices that an organization is using, in what is known as a dependency chain.

That means the provider of that product, service, or device is the one who needs to install the update. “The origin points for applications containing a vulnerable version of OpenSSL will vary, but that’s where the patches need to come from,” Mackey said. “It’s important to note that some origin points might not respond as quickly as others.”

Don’t get fooled again

It’s also important to make sure you’re getting a legitimate version of the update. Patrick Carey, senior director of security solutions at the Synopsys Software Integrity Group, noted in a video post that the advance notice of the update, while helpful to users, “creates additional risks because it allows bad actors during that same time frame to try to do targeted attacks to take advantage of the situation.”

“You need to be wary that when you’re pulling down a patch, it’s a legitimate, patched version of OpenSSL and not a tainted version put out by a hacker looking to fool you into putting malware into your code,” he said.

Mackey added that for organizations accustomed to getting their updates pushed to them from a single, authoritative, commercial vendor rather than an open source project, “this risk is heightened given how many forks, or branches, of OpenSSL exist. There are also many distribution channels for OpenSSL.”

So, there is good news. It could have been much worse. But if you don’t know if you’re using version 3.0 or above of OpenSSL you need to find out, quickly. Then you need to patch it — and make sure it’s the right patch.

As Jonathan Knudsen, head of global research within the Synopsys Cybersecurity Research Center, put it, “If you are already keeping an eye on your supply chain, then this OpenSSL thing should just be business as usual. If you are not aware of what’s going into your software, maybe this is the kick in the pants that gets you started with managing supply chain risk.”