OpenSSL releases fixes for two ‘high’ severity vulnerabilities

OpenSSL released patches for two vulnerabilities that have caused widespread concern among cybersecurity experts and researchers over the last week and a half. OpenSSL is a commonly used code library designed to allow secured communication over the internet.

The bugs announced on Tuesday – CVE-2022-3786 and CVE-2022-3602 – were listed as “high” by OpenSSL. The organization had initially caused alarm on October 25 by warning that its forthcoming release of OpenSSL version 3.0.7. would address a vulnerability rated “critical.”

OpenSSL said it had lowered the severity rating for the latter bug after they were given technical feedback about its details and spent the last week working with several organizations to test the issue. 

They noted that many modern platforms provide protections against the kind of attack enabled by the vulnerability.

“Our security policy states that a vulnerability might be described as CRITICAL if 'remote code execution is considered likely in common situations.' We no longer felt that this rating applied to CVE-2022-3602,” the project maintainers wrote in a blog post. 

“We still consider these issues to be serious vulnerabilities and affected users are encouraged to upgrade as soon as possible.”

Users of OpenSSL 3.0.0 - 3.0.6 are being urged to upgrade to the newest version as soon as possible by contacting a vendor or third party. The bugs do not affect earlier releases, since they were introduced in OpenSSL 3.0.0.

OpenSSL said it is unaware of any working exploit that could be used to take advantage of the issue and has no evidence that it is currently being exploited. 

CVE-2022-3602 was reported to OpenSSL on October 17 by a researcher auditing code. The next day another security researcher, Viktor Dukhovni, identified CVE-2022-3786.

Opinions on the vulnerability varied widely, with some saying OpenSSL use is ubiquitous, while others pointed out that most users deploy versions before OpenSSL 3.0.0.

Lotem Finkelsteen, head of threat intelligence at Check Point, said the potential consequence of this vulnerability “is massive.” 

“In many ways, 'the internet runs on OpenSSL' and everyone depends on OpenSSL,” he said.

“Whenever we browse the internet, the website we browse or the online service we access utilizes OpenSSL. Left unpatched, compromised server private keys or malicious remote code execution is possible, leaving user information exposed to bad actors.”

Nucleus Security’s Ryan Cribelar cast doubts on the vulnerability's severity, telling The Record that the situation will not resemble Heartbleed, a serious OpenSSL vulnerability found in 2014 that affected hundreds of companies and organizations. 

Cribelar added that the disclosure came at a good time because many organizations have not migrated over to version 3.0, which was released about a year ago. 

"Catching the vulnerability and squashing it this early in OpenSSL's 3.x life is a better scenario than most organizations being migrated over when it becomes disclosed,” he explained.

“All that being said, we think it's worth someone being a voice of reason and saying 'hey, don't panic, assess the situation and see what you're dealing with here.' The Nucleus team predicts that this is going to be less widespread, with fewer machines to remediate and the vuln squashed before most organizations have migrated to the vulnerable version of OpenSSL.”

While OpenSSL said it would not be giving the bugs a nickname akin to Heartbleed, Cribelar said his team has been referring to it as “heartbreak.” 

Yotam Perkal, director of vulnerability research at cybersecurity firm Rezilion, said a search on research tool Shodan showed fewer than 16,000 publicly accessible servers worldwide are running potentially vulnerable versions of OpenSSL, while about 238,000 servers are still vulnerable to HeartBleed, more than eight years after it was first published.

Most of those exposed are using versions 3.0.1 or 3.0.5, which make up about 13,000 instances combined. 

Several companies have created detection tools as a way to help users address the issue. Akamai’s tool found that about half of the environments it monitors had at least one machine with at least one process that depends on a vulnerable version of OpenSSL.

Within those networks, the percentage of machines that had some dependence on a vulnerable OpenSSL version ranged from 0.2% to 33%.  

Security company Censys found that as of October 30, nearly 1.8 million unique hosts have one or more services that claim to use OpenSSL but only 7,062 (0.4%) of those hosts run a version greater than or equal to version 3.0.0.

The company noted that the number of hosts running a 3.0.0 version of OpenSSL has slowly grown over the past few months from about 3,000 in August. 

Mark Ellzey, senior security researcher at Censys, said organizations that leverage Internet Explorer or Firefox may be impacted by a targeted attack and as a precaution, all organizations should review their corporate internet browser policies to ensure OpenSSL 3.0.0 - 3.0.6 is disabled.

Tenable’s Claire Tills said regardless of the scope, the vulnerabilities are not easy to exploit. Both vulnerabilities have to be triggered after certificate chain signature verification, meaning an attacker would likely need to get their malicious certificate signed, she explained. 

Jonathan Knudsen, head of global research at Synopsys Cybersecurity Research Center, said the two vulnerabilities patched on Tuesday are serious but not of the same magnitude as Heartbleed.

“Nobody’s hair should be on fire about these two vulnerabilities, but they are serious and should be handled with appropriate speed and diligence,” he said. 

Sonatype CTO Brian Fox said the issue was another prime example of why Software Bill of Materials are sorely needed across the tech industry.

“OpenSSL is so far reaching that understanding the full inventory is challenging, particularly when it’s embedded inside firmware or hardware devices,” Fox said. “Unless you’re able to ask the upstream provider, you likely won’t know where it’s embedded – transitive dependencies are a huge issue.”