OpenSSL CVE-2022-3602 and CVE-2022-3786 (Spooky SSL): What They Are and How to Mitigate Risk
Update as of November 4, 2022:
Forescout has just released an update of the eyeInspect dynamic threat detection capabilities (Threat Detection Add-Ons v1.14). This version introduces alerting for communications involving hosts using a vulnerable OpenSSL 3.0 version.
The detection is based on specific HTTP server header field patterns we found, in most cases related to Apache running on vulnerable Linux-based OS versions.
This detection strategy does not cover vulnerability exploitation attempts that require either endpoint detection solutions or TLS inspection, according to the available information.
We will continue updating our detection capabilities as additional information becomes available.
On November 1, OpenSSL v3.0.7 was released, patching two new high-severity vulnerabilities: CVE-2022-3602 and CVE-2022-3786. The new vulnerabilities have been dubbed by the community as “Spooky SSL,” although the name is not recognized by the OpenSSL team. CVE-2022-3602 was originally discovered by a researcher known as Polar Bear, while CVE-2022-3786 was found during the analysis of the first vulnerability by Viktor Dukhovni.
Spooky SSL had been pre-announced as a critical issue without further details by the OpenSSL team on October 25, prompting the security community to treat this as the next Heartbleed. As we will discuss below, the vulnerabilities turned out not to be as severe as Heartbleed and were downgraded from critical to severe.
Three observations are immediately important about Spooky SSL:
- CVE-2022-3602 can potentially lead to remote code execution (RCE). However, the OpenSSL team regards this as unlikely because of “the stack layout on common architectures and platforms and the fact that many modern platforms implement stack overflow protections.” Since OpenSSL is distributed as source code, RCE could still be possible on some platform and compiler combinations.
- The vulnerabilities only affect versions 3.0.0 until 3.0.6 of OpenSSL. The number of hosts on the internet running the affected versions is limited. More specifically, embedded IoT and OT devices typically use either embedded libraries such as mbedTLS and wolfSSL or older versions of OpenSSL (in the 1.0 branch) that are not affected by these issues.
- Currently, there is no evidence of these vulnerabilities being exploited in the wild. Vedere Labs is monitoring attacker activity on honeypots and will report if anything is detected.
In this blog post, we describe the two vulnerabilities and their impact as well as describe vuhow to detect vulnerable devices and mitigate risk.
Vulnerability descriptions and potential impact
OpenSSL is a popular library used to implement cryptography and encrypted network connections for applications such as HTTPS or VPN clients and servers. The library offers an open-source implementation of the SSL and TLS protocols written in the C programming language. The library also includes tools for generating RSA private keys and certificate signing requests.
CVE-2022-3602 is a buffer overrun vulnerability that can be triggered in X.509 certificate verification, specifically in name constraint checking. Certificate verification (vulnerable code trigger condition) occurs after certificate chain signature verification, that means an attacker must have a malicious certificate signed by a Certificate Authority or an application that continues certificate verification despite failure to construct a path to a trusted issuer (user ignores the warning).
An attacker can craft a malicious email address to overflow four attacker-controlled bytes on the stack. This buffer overflow could result in crash or potentially remote code execution. An attacker can exploit a TLS client by tricking it to connect to an attacker-controlled TLS server. A TLS server could be exploited for this vulnerability if it accepts client authentication from TLS clients. Exploiting this vulnerability is complex and primarily impacts the client side.
Figure 1. Attack scenario
CVE-2022-3786 refers to the variable length overflow variant in the X.509 email address field. An attacker can craft a malicious email address in a certificate to overflow an arbitrary number of bytes containing the `.’ character (decimal 46) on the stack. This buffer overflow could result in a crash causing a denial of service.
According to OpenSSL, these vulnerabilities were introduced in OpenSSL 3.0.0 following the addition of its punycode decoding functionality used for processing email address name constraints in X.509 certificates.
The OpenSSL team does not assign CVSS scores to their vulnerabilities, and the NVD has not assigned CVSS scores yet. Individual device and software vendors are continuously publishing security advisories that include detailed descriptions of impact on specific systems.
Detecting vulnerable devices
As was the case for Log4j, the OpenSSL library can be found in many types of software and devices. Further, there can be a system-wide version of the library shared by many applications on a device as well as different versions statically linked to specific applications. Therefore, identifying what devices have which vulnerable applications is a time-consuming process.
- To identify the system-wide version of OpenSSL on a device, run the following shell command on the target device: . The result will be something like OpenSSL X.Y.Z. IfY.Z is between 3.0.0 and 3.0.6, then the version is vulnerable.
- To identify versions of OpenSSL used by specific applications or processes on a device, there are several options, including YARA rules, OSquery, bash and PowerShell These scripts run over the whole filesystem on a device searching for vulnerable versions of the libraries.
With eyeSight, it’s possible to create a policy that will run one of those available scripts and group devices based on the script results.
Recommended mitigation
According to the OpenSSL team “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. Users operating TLS servers may consider disabling TLS client authentication, if it is being used, until fixes are applied.”
Forescout recommends the following mitigation steps:
- Discover and inventory vulnerable devices. Use the resources mentioned in the previous section to discover devices that have vulnerable versions of OpenSSL or follow the available vendor advisories.
- Patch vulnerable devices. There is no need for emergency patching since remote code execution is very unlikely and there is no indication of active exploitation. However, patching should still be prioritized whenever possible.
- Consider segmenting the network to mitigate the risk to vulnerable devices. Restrict external communication paths and isolate or contain vulnerable devices in zones as a mitigating control if they cannot be patched or until they can be patched.
- Monitor all network traffic for malicious packets that try to exploit the vulnerabilities. Snort rules to detect exploitation of Spooky SSL are available. Note that these rules require TLS inspection.
References and further resources
- Official OpenSSL advisory and blog
- Collection of resources, including affected software and scanning techniques, maintained by the NCSC-NL
- Technical details of exploitation and patch diff
- More technical details of the vulnerabilities