High-Severity Vulnerabilities Addressed in OpenSSL Update

Highly anticipated critical vulnerabilities in current versions of OpenSSL were downgraded to high severity by the OpenSSL Project today, which patched the flaw in version 3.0.7. OpenSSL’s advisory can be found here.

The downgrade should not lessen the rush to update current deployments, OpenSSL said, despite several mitigating factors reported by users who tested their systems for the vulnerabilities. 

OpenSSL added there are no reports of public exploits for either CVE-2022-3786 or CVE-2022-3602. Both vulnerabilities are buffer overflows that could lead to crashes or in some rare cases to remote code execution; they affect functionality that processes email address name constraints in X.509 certificates.

OpenSSL is everywhere within IT, operational technology, and connected embedded systems. Many commercial and homegrown software projects include OpenSSL as their cryptographic key solution.

A blog published today by OpenSSL explains that several organizations doing testing on systems running affected versions of the crypto library reported two mitigating factors that blunted the effects of the vulnerability and led to the downgrade in severity from critical to high severity. 

“Firstly, we had reports that on certain Linux distributions the stack layout was such that the 4 bytes overwrote an adjacent buffer that was yet to be used and therefore there was no crash or ability to cause remote code execution,” OpenSSL said. “Secondly, many modern platforms implement stack overflow protections which would mitigate against the risk of remote code execution and usually lead to a crash instead.”

Since OpenSSL is open source, maintainers caution there could still be a risk of remote code execution exploits. 

“We have no way of knowing how every platform and compiler combination has arranged the buffers on the stack and therefore remote code execution may still be possible on some platforms,” OpenSSL said in its blog. Users who have OpenSSL 3.0 and later running under the hood of commercial software should work with their respective vendors on updates. 

Several entities have published lists of affected Linux distributions and other software projects that may be impacted by the vulnerabilities, including SANS Institute and the Netherlands' National Cyber Security Centre.

“Any OpenSSL 3.0 application that verifies X.509 certificates received from untrusted sources should be considered vulnerable,” OpenSSL said. “This includes TLS clients, and TLS servers that are configured to use TLS client authentication.” OpenSSL also said that users operating TLS servers may disable TLS client authentication until fixes are applied, if appropriate within their environment.

The last critical vulnerability publicly disclosed and patched by OpenSSL was in September 2016 when an emergency security update addressed a flaw introduced by an earlier update. The patch in question introduced a dangling pointer vulnerability that could lead to server crashes or remote code execution. 

2014’s Heartbleed vulnerability is one of the biggest internet-wide bugs of the 21st century. Heartbleed leaked memory to any client or server that was connected, and that exposed servers to attack. It also kicked off a major patching frenzy at the time as administrators scrambled to understand where OpenSSL was deployed within their infrastructure, and whether it could be updated before exploits were made public.