On November 1, 2022, OpenSSL developers released details of two vulnerabilities: CVE-2022-3786 and CVE-2022-3602.
Context
In an accompanying blog post, OpenSSL explained that they downgraded the severity of the vulnerabilities to high from the originally announced critical level due to technical barriers to exploitation. No in the wild exploits or proofs of concept (POCs) are currently known.
Technical Details
In the vulnerability disclosure, the CVEs are detailed as follows:
- CVE-2022-3786 (OpenSSL advisory) [HIGH severity] 01 November 2022:
- A buffer overrun can be triggered in X.509 certificate verification, specifically in name constraint checking. Note that this occurs after certificate chain signature verification and requires either a CA to have signed a malicious certificate or for an application to continue certificate verification despite failure to construct a path to a trusted issuer. 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). In a TLS client, this can be triggered by connecting to a malicious server. In a TLS server, this can be triggered if the server requests client authentication and a malicious client connects. Reported by Viktor Dukhovni.
- Fixed in OpenSSL 3.0.7 (git commit) (Affected 3.0.0,3.0.1,3.0.2,3.0.3,3.0.4,3.0.5,3.0.6)
- CVE-2022-3602 (OpenSSL advisory) [HIGH severity] 01 November 2022:
- A buffer overrun can be triggered in X.509 certificate verification, specifically in name constraint checking. Note that this occurs after certificate chain signature verification and requires either a CA to have signed the malicious certificate or for the application to continue certificate verification despite failure to construct a path to a trusted issuer. An attacker can craft a malicious email address to overflow four attacker-controlled bytes on the stack. This buffer overflow could result in a crash (causing a denial of service) or potentially remote code execution. Many platforms implement stack overflow protections which would mitigate against the risk of remote code execution. The risk may be further mitigated based on stack layout for any given platform/compiler. Pre-announcements of CVE-2022-3602 described this issue as CRITICAL. Further analysis based on some of the mitigating factors described above have led this to be downgraded to HIGH. Users are still encouraged to upgrade to a new version as soon as possible. In a TLS client, this can be triggered by connecting to a malicious server. In a TLS server, this can be triggered if the server requests client authentication and a malicious client connects. Reported by Polar Bear.
- Fixed in OpenSSL 3.0.7 (git commit) (Affected 3.0.0,3.0.1,3.0.2,3.0.3,3.0.4,3.0.5,3.0.6)
In their blog post, developers indicated that they reduced the severity of the vulnerabilities for two key reasons:
- “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.
- 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.”
Researchers at DataDog Security Labs provided the following breakdown of the required steps for exploitation:
Potential Impact
In their blog post, OpenSSL developers indicated “exposure to remote code execution is not expected on any platforms.”
Multiple security researchers on social media and in blog posts noted that the vulnerabilities exist on the client side, requires threat actors to craft a malicious certificate and get the certificate signed by a trusted certificate authority (CA), and only a narrow range of OpenSSL (3.0.0 through 3.0.6) is affected. Thus, the impact of the vulnerabilities is likely to be low and remote execution is not likely due to the obstacles required for exploitation.
Another security researcher noted that “In most default config Linux distributions, stack overflow protections will automatically mitigate code execution,” further reducing the risk of exploitation.
Mitigation Options
OpenSSL developers recommended that “Users of OpenSSL 3.0.0 – 3.0.6 upgrade to 3.0.7 as soon as possible. If users obtain their copy of OpenSSL from Operating System vendor or other third party then users should seek to obtain an updated version as soon as possible.”
Researchers at DataDog Security Labs provided the following detection and remediation options:
- “If your operating system comes with a vulnerable version of OpenSSL installed (e.g., Ubuntu 22.04 LTS or Amazon Linux 2), any application dynamically loading the OpenSSL library is vulnerable as well. That’s typically the case of web servers like Nginx or Apache2 and interpreted languages such as PHP, Python, or Ruby.
- If you’re using an application runtime that packages its own OpenSSL version, such as Node.js 17.x, 18.x or 19.x, you need to upgrade the runtime itself. Upgrading the operating system openssl package is not enough.”
