OpenSSL has released fixes for high-severity vulnerabilities affecting versions 3.0.0 through 3.0.6 that can cause a denial of service or remote code execution and allow attackers to take control of an affected system. However, the bugs are not as severe as once feared.
The OpenSSL project, the organization that maintains the general-purpose cryptography and secure communication toolkit, originally warned IT administrators and users that version 3.0.7 would fix a critical security flaw, but that has since been downgraded to high severity.
However, users and administrators are still being urged to upgrade to OpenSSL 3.0.7 where available, and third-party software providers are also impacted and will be upgrading their systems to reflect the patch.
According to OpenSSL’s blog, the 3.0.7 release was originally announced as a fix for a critical vulnerability last week, but both CVE-2022-3786 and CVE-2022-3602 are listed as only high severity after the latter was downgraded based on further research that suggests remote code execution is less likely. Meanwhile, the former bug was rated as high severity from the outset.
Tugs are not currently being exploited in the wild and they don’t affect any versions prior to 3.0, according to the OpenSSL project.
Despite the downgrade in severity, there is still a long list of software providers that use affected versions of OpenSSL, so admins should review the list and apply any patches with speed. The U.S. Cybersecurity & Infrastructure Agency and the Netherland’s National Cyber Security Centrum are maintaining a GitHub repository of impacted software.
According to Philippe Laulheret, senior security researcher at Trellix, says bringing the situation to light days in advance created unjustified anxiety. Only a fraction of the total use base of OpenSSL use the vulnerable eversions, and the organization’s work to release version 3.0.7 to patch the vulnerabilities is a win for the IT and security community, he says.
Now, the effort needs to focus on identifying exposure to the vulnerable code across operating systems, third-party software and internal use of the OpenSSL library, Laulheret says, adding that the downgraded vulnerabilities should still be mitigated immediately.
“The original critical rating sparked fear this would be the next Heartbleed but we can see now that this is not the case,” he says. “Heartbleed was easy to exploit and would leak private server information, while these two bugs are memory corruption bugs that are heavily lessened by modern OS and compiler security mitigations.”
Brian Fox, co-founder and chief technology officer at open source security firm Sonatype, says the details of these bugs indicate that successful exploitation is very difficult. The vulnerability requires a malformed certificate that is trusted or signed by a naming authority, meaning that authorities should be able to quickly prevent certificates designed to target this vulnerability from being created, further limiting the scope.
Fox says preannouncing the bugs a week early may have actually helped to drive awareness and faster patching. The company’s own research suggests that more publicity of a security flaw makes IT departments and developers act more quickly.
Still, though, some will be unprepared, Fox says.
“I think some people might be let down that it’s not as bad as they hoped. I think that is evidence of success, because the opposite is that everyone is scrambling and woefully unprepared,” says Fox. “Recent studies have found that there are still several hundreds of thousands of servers still running versions of OpenSSL susceptible to Heartbleed which was disclosed eight years ago.”
If you enjoyed this article and want to receive more valuable industry content like this, click here to sign up for our digital newsletters!