Note: This Bulletin was contributed to by Kudelski Security’s Threat Detection & Research Team. Specifically Mark Stueck.

Executive Summary

On the 25th of October, the OpenSSL project announced the upcoming version of OpenSSL 3.0.7, which would include a patch for what at the time was noted as a critical severity vulnerability in previous versions of OpenSSL 3.0.x. On November 1st, two vulnerabilities were disclosed: CVE-2022-3786 and CVE-2022-3602, which describe two buffer overflows in punycode decoding functions. Following the announcement, CVE-2022-3602 was downgraded to high severity following feedback from security researchers conducting additional testing and investigation.

The primary high severity vulnerability (assigned CVE-2022-3602) exists due to how OpenSSL 3.0.x attempts to decode email addresses included in certificates during name constraint checking. In OpenSSL 3, this occurs after certificate chain validation. As such, successful attacks require that an attacker have access to a malicious certificate signed by a publicly trusted Certificate Authority (CA) or by a certificate authority explicitly trusted by the victim (such as a self-signed certificate or one signed by a private CA).

Additionally, successful exploitation of this vulnerability for Remote Code Execution (RCE) would require that attackers bypass memory protections built into operating systems such as Address Space Layer Randomization (ASRL), No Execute Memory Protection, Etc. While this is possible, creating reliably exploits would require that such exploits be targeted against specific Operating System versions or software appliances. As such, the CFC strongly recommends that organizations apply patches for affected system expediently, but this is currently not a critical situation that requires 24/7 remediation efforts.

As of this writing, the Kudelski Security Fusion Premise Equipment (FPE) appliances are not vulnerable to either CVE-2022-3786 or CVE-2022-3602.

Affected Components

The vulnerability affects only OpenSSL versions 3.0.0 and above until 3.0.6. Versions 1.1.1 and 1.0.2 are not affected. At the time of writing, some of the affected Operating Systems include Debian 12, Ubuntu Linux 22.04 (Jammy), Ubuntu Linux 22.10 (Kinetic), Linux Mint 21 (Vanessa), and several recent versions of Fedora Linux (36, 36, Rawhide, and EPEL versions 7 & 8).

Due to the rapidly changing nature of the list of potentially impacted software, Kudelski Security strongly recommends that organizations review the following Github repo maintained by the Netherland’s National Cyber Security Center (NCSC-NL) and being contributed to by members of the community:

https://github.com/NCSC-NL/OpenSSL-2022/tree/main/software

Additionally, Docker has released a tool to search Docker & container images which include vulnerable versions of OpenSSL.

Technical Details

The problems are two buffer overflows in punycode decoding functions of OpenSSL. The commits correcting the problems are available here and here.

Punycode is a way to represent Unicode characters with an ASCII-only character set. This is used by OpenSSL to represent domains that contain Unicode characters. For example, the Unicode string “öpenssl 💣” will be converted to “xn—penssl -80a47326i” in punycode.

A way to limit the scope of a Certificate authority (CA) is to use name constraints. Name constraints allow limiting domain names of the issued certificates. The vulnerabilities arise when the email field of the name constraints is parsed. The email can contain puny-encoded values, and the parser implemented in OpenSSL 3.0.x wrongly decodes them. The buffer length is improperly checked and attacker-controlled 4 bytes may overflow the buffer.

The second vulnerability (CVE-2022-3786) can be exploited by attackers through the use of malicious email addresses to trigger denial-of-service by way of buffer overflow attacks. However, unlike CVE-2022-3602, only the length of the buffer can be manipulated by attackers as opposed to the content.

Note: In both cases, exploitation occurs after certificate chain signature verification, meaning a CA or intermediate will need to contain the malicious payload and must sign the leaf certificate in order to facilitate successful exploitation.

Colm MacCárthaigh released very quickly a proof of concept code for CVE-2022-3602, which allows playing with the vulnerability and explains the details.

When running the code against a non-vulnerable OpenSSL version the following output should display:

Certificate request self-signature ok
subject=C=US, ST=WA, L=Seattle, O=PunyCode Corp, OU=PunyCode Dept, CN=www.example.com
test case 0 ... ok
test case 1 ... ok
test case 2 ... ok
test case 3 ... ok
test case 4 ... ok
test case 5 ... ok
test case 6 ... ok
test case 7 ... ok
test case 8 ... ok
test case 9 ... ok
test case 10 ... ok
ctrl-c when ready

However, running the code against a vulnerability version of OpenSSL (such as 3.0.6) returns the following:

Certificate request self-signature ok
subject=C=US, ST=WA, L=Seattle, O=PunyCode Corp, OU=PunyCode Dept, CN=www.example.com
test case 0 ... possibly vulnerable
test case 1 ... possibly vulnerable
test case 2 ... possibly vulnerable
test case 3 ... possibly vulnerable
test case 4 ... possibly vulnerable
test case 5 ... possibly vulnerable
test case 6 ... possibly vulnerable
test case 7 ... possibly vulnerable
test case 8 ... possibly vulnerable
test case 9 ... possibly vulnerable
test case 10 ... possibly vulnerable
ctrl-c when ready

Another proof of concept was published by Datadog Security labs for the Windows version of OpenSSL. A second scenario was run for a replicated Linux environment, which resulted in a medium-confidence rating for exploitation possibility as a result of several low-level technological factors.

Solution

Even though the vulnerabilities were downgraded from “critical” severity to high severity, it is still necessary to correct the issues. As such, the CFC strongly recommends that organizations apply patches for affected system expediently, but this is currently not a critical situation that requires 24/7 remediation efforts.  The solution is to update to OpenSSL version 3.0.7 when possible. As part of our own internal patching validation process, our internal team at Kudelski Security put together the following decision diagram:

What the Cyber Fusion Center is doing

The CFC has worked to validate that at the time of this writing, the Fusion Premise Equipment (FPE) is not vulnerable to CVE-2022-3786 or CVE-2022-3602.

Additionally, the CFC is working with our vendor partners to identify potentially vulnerable systems that should be patched by the CFC’s Security Device Management (SDM team). The CFC will provide clients updates regarding potentially vulnerable systems and patching plans as our vendor partners validate their overall exposure to these OpenSSL vulnerabilities.

Conclusion

Exploitation of CVE-2022-3602 and CVE-2022-3786 may result in RCE or DoS attacks. However, several factors and conditions within the environment must be true in order for this to be possible. Furthermore, these vary significantly from environment to environment, indicating that successful exploitation across a broad range of systems would require complex and sophisticated techniques.

For example, due to the common buffer overflow protections, such as ASLR, NX stack, stack cookies, SafeSEH, and platform-specific protections, buffer overflow attacks are, in general, increasingly difficult to execute successfully. Also, attack progression may also require additional techniques such as heap spray attacks, which reduce subtly and increase detection possibilities, in order to effectively manipulate unallocated memory.

Additionally, successful denial-of-service relies on a specific stack layout found within the ossl_a2ulabel function. Essentially, exploitation conditions vary considerably based on specific factors such as compiler optimization settings and whether or not stack cookies are disabled.

In both instances, patching to OpenSSL version 3.0.7 is highly recommended. Lastly, review current buffer overflow protections and, if you are unsure, contact Kudelski Security for best practices and guidelines.

Sources

Baguelin, F., Fox, J., Frichette, N., Salem, E. (2022 Nov 1). The OpenSSL punycode vulnerability (CVE-2022-3602): Overview, detection, exploitation, and remediation. DATADOG Security Labs | Emerging Threats Blog. https://securitylabs.datadoghq.com/articles/openssl-november-1-vulnerabilities/

Farrell, N. (2022 Nov 1). OpenSSL flaw should be patched today. FudZilla. https://www.fudzilla.com/news/55751-openssl-flaw-should-be-patched-today

NCSC-NL | OpenSSL-2022. (2022 Nov 1). CERT Netherlands. https://github.com/NCSC-NL/OpenSSL-2022/blob/main/software/README.md

OpenSSL Security Advisory. (2022 Nov 1). OpenSSL Project. https://www.openssl.org/news/secadv/20221101.txt

SentinelOne. (2022 Nov 1). OpenSSL 3 Critical Vulnerability | What Do Organizations Need To Do Now? SentinelOne. https://www.sentinelone.com/blog/openssl-3-critical-vulnerabililty-what-do-organizations-need-to-do-now/

Ullrich, J. B. Upcoming Critical OpenSSL Vulnerability: What will be Affected? SANS Institute – Internet Storm Center. https://isc.sans.edu/forums/diary/Upcoming+Critical+OpenSSL+Vulnerability+What+will+be+Affected/29192