blog post cover

OpenSSL Vulnerability Once Heartbleed-Level “Critical” Now Deemed “High”

I was there, Gandalf, 3000 years ago (8 actually) when the Heartbleed bug in the OpenSSL library was exposed as one of the worst vulnerabilities in recent history. In short and simple terms, it broke the encryption and allowed unauthorized access to the recent memory contents of a server, which would most likely include the private data from previous requests or even encryption keys. 

It was a huge event. Many failed to patch their servers properly, and many online services issued password resets just in case. For a history lesson, see the Wikipedia page. There were also many discussions that OpenSSL was severely underfunded. As a critical software component used by millions of software developers, it should not be the case, given the tech salaries everywhere. 

funny image about modern digital infrastructure
See the relevant XKCD.

There is also a fork called LibreSSL, created after Heartbleed, which recently became the default TLS provider in macOS.

So, after 8 years, a similar vulnerability happened again. Well, sort of. There has been a suspension in the last week that OpenSSL would release a critical patch on Nov 1st. There was an embargo, which is usual for critical vulnerabilities at the center of the internet, preventing further discussion because of the possibility of causing mass exploits everywhere. 

If you have known about Heartbleed for a week, you could extract tons of data undetected from thousands of servers, so an embargo makes sense. However, with the blockade comes the suspension. Security vendors worldwide started placeholder blog posts and advisories for their customers and marketing purposes. See Google Trends for it.

Google Trends results for OpenSSL vulnerability

It was a hugely overblown vulnerability that only caused mass panic with immense frustration. The severity was downgraded from Critical to High before the embargo lift. Unlike Heartbleed, the client and servers need to be configured in an unusual way to allow an exploit to work. Additionally, it affects 3.0.x versions, which is not an LTS (long-time support) version, and the adoption is low. 

So, why the fuss? There are vulnerabilities announced every day. But when it comes to a fundamental library like OpenSSL, it causes mass hysteria, possibly due to the collective trauma of Heartbleed or Log4Shell, which happened this year. In 2014, most of us did not have visibility of dependencies, software supply chains, and cloud assets. Even if we did, the automated ways to patch things at scale reliably were scarce. Today, thanks to security scanners and quick CI/CD pipelines, it'd be a crime not to respond quickly to such an incident.

The reason for the fuss is that fear sells in cyber-security. Remember when Uber was hacked due to a credential found on a network device, and one of the excessive MFA requests was approved, and hackers were in? Many vendors tried to pitch their services or products as "Don't be like Uber; here is how not to do the exact things that happened in the Uber attack."

a tweet by Daniel Grzelak

This situation is not entirely different; it was known that the vulnerability only affected 3.x versions, which is not widespread. According to Wiz, only 1.5% of OpenSSL instances were affected. However, similar to the Uber case, many security vendors exploited the OpenSSL vulnerability to promote their products by fear-mongering, so to speak. Blog posts, hashtags, and all, just to name a few.

Don't panic

While the initial warning caused turmoil, prompting CIOs and CISOs to take immediate action to mitigate potential security threats, the "real" deal had less impact. The CVE-2022-3602, initially rated as critical, has been downgraded to high severity. It only impacts OpenSSL 3.0 and later instances. Plus;

  • The Netherlands' National Cyber Security Centre maintains an overview of software products (un)affected by the OpenSSL vulnerability.
  • The most recent releases of multiple popular Linux distributions include the latest OpenSSL versions, with Ubuntu 22.04+, Debian 12, CentOS Stream9, Redhat Enterprise Linux 9, Fedora 36, and Kali 2022.3 classified as vulnerable by cybersecurity company Akamai.

For what it's worth, don't mass-rush into huge cybersecurity investments out of fear; make sure to have guardrails up at all times and maintain crystal-clear visibility over your environments.

Suggested reading: What is CyberSecurity Attack Surface Management?

Continue Reading

Sign up for our Newsletter