OpenSSL Vulnerability Analysis — Denial of Service and Remote Code Execution

In today’s post, we provide insights regarding two new vulnerabilities that have been uncovered in the OpenSSL library — CVE-2022-3602 and CVE-2022-3786. These vulnerabilities affect OpenSSL versions 3.0.0 — 3.0.6 but have been patched in the recent version 3.0.7.

Both have been rated HIGH severity. However, of the two, CVE-2022-3602 is considered more critical. Though still critical, CVE-2022-3786, Denial of Service, is less urgent. We have yet to see any active attack or exploit in the wild; however, we expect some could occur over the next few weeks.

To find out if you’re using vulnerable software, GitHub has a list of affected and unaffected software on its site here. In this blog post, we will take a deeper look at CVE-2022-3602 and the urgent risks it presents to organizations.

CVE-2022-3602 — OpenSSL Remote Code Execution (RCE)

The vulnerability can affect servers that require client authentication and may lead to critical remote code execution. If your server requests client authentication with X.509 certificate verification, or has a flow that validates such a certificate, an attacker can craft a malicious field (email address) in a certificate to exploit a classic buffer overflow. This buffer overflow could result in a crash (causing a denial of service) and, in some cases, may lead to remote code execution on your server.

The CVE-2022-3602 was originally assessed by the OpenSSL project as CRITICAL because of its potential to lead to remote code execution but was changed to HIGH after researching the stack layout with the conclusion that a remote code is less likely to happen.

To understand this, let's take a look at the vulnerable piece of code, in the function ossl_punycode_decode:

As part of parsing and converting a punycode string to unicode, the memmove function copies bytes from left to right by one byte (dword to be more accurate — unsigned int). To make sure memmove doesn't move/copy bytes outside of pDecoded, the code must check that the last byte memmove writes “to” is not bigger than the size of pDecoded in the stack, which is max_out.

To be more specific, the following condition must be checked by the code:

i + 1 + (written_out - i) < maxout

Since i-i is 0, we have a simpler condition:  written_out + 1 < maxout

However, the check in line 183 omits the "+1", leadining to a potential overflow by one dword (sizeof unsigned int). This is 4 bytes dangerous buffer overflow.

OpenSSL published the following fix here, changing (written_out > max_out) to (written_out >= max_out), which also solves the issue.

However, to understand the impact of those 4 bytes, we need to understand exactly what is located in the stack near pDecoded. For example, if there is a pointer in that place, the attacker could cause the server which uses OpenSSL to run a malicious code instead of the original flow. While not easy, this type of attack is theoretically possible.

The answer varies between different uses of OpenSSL, in combination with different compilers.

In the common scenario, as the OpenSSL security team wrote, the stack layout was such that the 4 bytes overwrote an adjacent buffer that was yet to be used. Therefore, remote code execution was less likely to happen.

By looking a bit deeper, ossl_punycode_decode is invoked from ossl_a2ulabel. In ossl_a2ulabel, pDecoded is a LABEL_BUF_SIZE (512) sized array of unsigned int. The total size on the stack is 512*4 = 2048.

In ossl_a2ulablel, there seems to be a seed variable after pDecoded in the stack, which means that the attacker can control its value.

However, this happens before the variable is initialized and therefore has no effect on the program (the value of the attacker will be overwritten anyway). In other scenarios, the compiler may ignore the seed variable because of optimization, which means that the stack cookie will be overwritten, which will cause the program to crash.

Even if the attacker finds a specific implementation/use of OpenSSL with a significant variable in the stack near pDecoded, they would  still need to bypass several stack overflow protections which exist on any platform and software by default.

Having exploited similar vulnerabilities, we know that it is not trivial to exploit it, and it may take some time to see a working exploit with remote code execution. Nevertheless, this CVE may motivate attackers to search for additional vulnerabilities in the OpenSSL library. It’s always important to ensure your server is protected against those attacks, especially if there is no available patch like in zero day vulnerabilities.

To learn more about how Salt can help defend your organization from API risks, you can connect with a rep or schedule a personalized demo.