New OpenSSL vulnerabilities allocated CVE-2022-3602, CVE-2022-3786. Downgraded from “critical” to “high”. Affect 3.0.0 to 3.0.6, do not provide Remote Code Execution (RCE). Questions raised about OpenSSL QA.
There are two new vulnerabilities in OpenSSL — the ubiquitous open source toolkit and cryptographic library used by much enterprise software, as well as by web servers to establish encrypted HTTPS connections.
They have been downgraded from “critical” to “high” after being found unlikely to lead to Remote Code Execution (RCE) following external testing in what is a relief for Blue Teams and product owners — and a damp squib for offensive security researchers who had been eagerly anticipating details about the vulnerabilities.
OpenSSL is a toolkit for the Transport Layer Security (TLS) protocol formerly known as the Secure Sockets Layer (SSL) protocol. It is used in mail servers and VPN protocols to establish encrypted communication channels.
The library can also be found in a broad array of products, including network devices, embedded systems and container images. The vulnerabilities have been allocated CVE-2022-3602 and CVE-2022-3786.
CVE-2022-3602 and CVE-2022-3786: What’s the risk?
The vulnerabilities affects OpenSSL version 3.0.0 to 3.0.6, with the patch being shipped in version 3.0.7.
CVE-2022-3602, attributed to “Polar Bear” (aka SandboxEscaper) is an “arbitrary 4-byte stack buffer overflow” and had been feared to trigger RCE but this does not appear to be the case. OpenSSL warned however: “any OpenSSL 3.0 application that verifies X.509 certificates received from untrusted sources should be considered vulnerable. This includes TLS clients, and TLS servers that are configured to use TLS client authentication”
Due to the fact OpenSSL 3.0.0 was released in September 2021, it is less widespread than previous versions.
Just over 15,000 publicly accessible web servers worldwide are running 3.0+
Follow The Stack on LinkedIn
The vulnerable versions of OpenSSL are widely used in Linux operating systems including Ubuntu 22.04 LTS, MacOS Ventura, Fedora 36, and others like Amazon Linux 2022. Whilst organisations like the Dutch NCSC had been tracking potentially exposed products here and many security researchers had anticipated a potential Log4J-type crisis, a blog published today by OpenSSL committers emphasised that “many modern platforms implement stack overflow protections which would mitigate against the risk of remote code execution”.
Reports of a critical OpenSSL vulnerability has gained huge attention across the cybersecurity community because the last critical OpenSSL vulnerability, “Heartbleed, in 2016 resulted in widespread exploitation.
The OpenSSL foundation on October 25 had announced the critical fix was pending, but had faced stark criticism for not giving security vendors an early look at the vulnerability to develop detections or mitigations.
Experienced CISO Alyssa Millar was among those raising concern, saying on October 28: “Every vendor I’ve spoken with about this has said they’ve gotten no details. So OpenSSL have basically announced to attackers and defenders alike that the starting gun fires on Tuesday and the race is on. This is pitiful.”
The open source project’s disclosure policy does say that it will “prenotify certain organisations with more details and patches” including “those that produce a general purpose OS that uses OpenSSL; other open source projects that are derived from OpenSSL which have a significant user base and a reciprocal arrangement” and “may include organisations with which we have a commercial relationship” but this does not appear to have included most security vendors with like Check Point and F5 among those earlier confirming they had no early details.
VMware was among those rapidly confirming its products were not affected but “regardless, VMware products that consume OpenSSL 3.0.x will consume 3.0.7 fixes as a precautionary measure in upcoming releases.”
Dave Kennedy, CEO of TrustedSec, noted: “The implications here really are more phishing related (client side attacks) + rare client-side authentication implementations.” More details to follow.