Background
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.
We had also published a blog with steps you can perform to protect your organization.
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.
One of the key benefits of adopting a cloud-native SSE platform, in contrast with legacy NGFW appliances or virtual machines, is that Zscaler takes away from the end customers the operational overhead of patching software across a sprawl of legacy hardware appliances and virtual machines. A nice illustration of this benefit was also seen earlier this year when it took us just a few days to patch against the March 2022 CVE-2022-0778 OpenSSL Vulnerability.
How Zscaler protects users from this vulnerability
As of now, there are no known in-the-wild exploit attempts reported for these vulnerabilities, but security researchers have published a successful exploitation POC. ThreatLabz is actively monitoring and will ensure coverage against threat activity targeting end-users protected by Zscaler. Even though this issue can potentially impact both TLS clients and TLS servers, the likelihood of a client exploiting a server using a malicious client TLS certificate is much lower, given that mTLS (mutual TLS in which a server authenticates a client as well) is not widely used.
Zscaler’s proxy based architecture and SSL inspection service are well positioned to defend against exploitation attempts targeting end users through maliciously crafted server certificates. As a trusted man-in-the-middle (MITM), Zscaler scans and validates all server certificates, centrally in the cloud as if Zscaler is the client browser for the destination TLS server, and issues a new server certificate signed by Zscaler’s or a customer’s issuing CA, essentially preventing the bad cert from ever getting to the end-user.
As long as customers have enabled SSL/TLS inspection, Zscaler will defend against the threat as illustrated below:
1. Attacker hosts a malicious site serving the specially crafted X.509 certificate triggering the OpenSSL vulnerability.
2. End-user is tricked to access the malicious site via Zscaler with TLS inspection enabled.
3. If the server name has a bad reputation, Zscaler will immediately drop the connection.
4. Otherwise, Zscaler will terminate the TLS handshake request from the client and initiate its own handshake with the destination server.
5. Zscaler validates the certificate sent by the server after the ServerHello. Since Zscaler is not vulnerable to the OpenSSL vulnerability issue, Zscaler’s infrastructure itself is safe.
6. Zscaler generates a domain certificate and sends it to the end-user. Since Zscaler issues only properly crafted X509 certificates, the exploit attempt is effectively neutralized. The malicious certificate will never make its way to the end-user.
Figure 1: Zscaler TLS inspection preventing OpenSSL vulnerability exploit attempt
Check out our recent blog post to learn more about how SSL inspection works and the key responsibilities assumed as an SSL proxy.
How Zscaler helps organizations secure workloads impacted by this vulnerability
For workloads, Zscaler Posture Control allows organizations to scan all of your AWS, Azure, and GCP environments to help identify and prioritize the assets that require attention. Out of our customers, 12% found immediate results and discovered that they have workloads vulnerable to these issues. Most of the vulnerable workloads were found specifically in public-facing assets.
References
