On 01-Nov-2022, OpenSSL published an advisory about two high-severity security flaws - CVE-2022-3786 (“X.509 Email Address Variable Length Buffer Overflow”) and CVE-2022-3602 (“X.509 Email Address 4-byte Buffer Overflow”). These vulnerabilities affect OpenSSL version 3.0.0 and later and have been addressed in OpenSSL 3.0.7.
What is the issue?
The following vulnerability details were published in the OpenSSL security advisory earlier today:
A buffer overrun can be triggered in X.509 certificate verification, specifically in name constraint checking. 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.
A buffer overrun can be triggered in X.509 certificate verification, specifically in name constraint checking. 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.
What versions are impacted?
OpenSSL versions 3.0.0 to 3.0.6 are impacted by these vulnerabilities. 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. OpenSSL 1.0.2, 1.1.1 and other earlier versions are not affected.
What can you do to protect yourself?
Users of OpenSSL 3.0.0 - 3.0.6 are encouraged to upgrade to 3.0.7 as soon as possible. If you obtain your copy of OpenSSL from your Operating System vendor or other third-party then you should request an updated version from them as soon as possible.
Users operating TLS servers may want to consider disabling TLS client authentication until fixes are applied.
Zscaler Cloud is not impacted
We have completed our review and published a trust post to notify our customers that Zscaler cloud components are not impacted by this vulnerability.
How Zscaler protects its Users from this Vulnerability
As of now, there are no in-the-wild exploit attempts reported for these vulnerabilities. ThreatLabz is actively monitoring and will ensure coverage against activity targeting these vulnerabilities. Our proxy based architecture will provide indirect protection against this issue, provided the customer is performing TLS inspection for the malicious destination.
While this issue impacts both TLS client and server, let us look at an example of TLS client being attacked:
Attacker hosts a malicious site serving the specially crafted X.509 certificate triggering the OpenSSL vulnerability.
Customer tries to access the malicious site via Zscaler with TLS inspection enabled for the destination.
Zscaler will terminate the TLS connection and serve a legitimate Zscaler certificate to the customer endpoint. Zscaler enforcement node is not vulnerable to the issue thereby mitigating the exploit.
Figure 1: Zscaler TLS inspection preventing OpenSSL vulnerability exploit attempt
In addition to various security coverage for blocking malicious destinations, customers will be automatically protected from these vulnerability exploits by our proxy based architecture as long as they are performing TLS inspection for the destination.
https://www.openssl.org/blog/blog/2022/11/01/email-address-overflows/ https://www.openssl.org/news/secadv/20221101.txt https://trust.zscaler.com/zscaler.net/posts/12411
Article Link: Security Advisory for OpenSSL Vulnerabilities CVE-2022-3602 & CVE-2022-3786 | Zscaler