Background
On 1st November 2022, at 15:36:42 UTC, the Downloads page of OpenSSL was updated with two new tar files, one of which was associated with OpenSSL 3.0.7. This was shortly followed by an announcement by the OpenSSL team at 15:42:06 UTC. OpenSSL had just fixed two vulnerabilities in 3.0.6, a move which the entire information security industry was waiting for. The announcement mentioned that the upcoming release of 3.0.7 would be a security-fix release and that the highest severity issue fixed in the release would be CRITICAL.
This announcement started spreading like wildfire within the industry, and in no time, everyone had started to prepare for the upcoming release and make sure that their systems were updated with the patch as soon as it was released. While some people suggested that it would be somewhat similar to “Heartbleed”, which was an earlier vulnerability in OpenSSL which shook the industry to its core, others believed it to be an overhyped patch.
But finally, when the patch was released on 1st November 2022, the OpenSSL team downgraded the severity issue from CRITICAL to HIGH. A move which came unexpectedly to many. The team released the advisory related to two HIGH severity vulnerabilities, CVE-2022-3786 and CVE-2022-3602. But what are these vulnerabilities? Why was a vulnerability degraded from CRITICAL to HIGH? How exactly can these vulnerabilities be exploited? This blog aims to answer all of these questions and many more.
So what exactly is OpenSSL?
OpenSSL is a general-purpose cryptography library developed in C that provides an open-source implementation of the Secure Sockets Layer (SSL) and Transport Layer Security (TLS) protocols. It is adapted by the majority of the HTTPS web applications hosted on today’s internet for encryption and security. With OpenSSL, you can apply for your digital certificate and install the SSL files on your server.
Historically, OpenSSL faced a serious vulnerability in the year 2014, which was named the “Heartbleed” bug (CVE-2014-0160). When exploited, it leads to the leak of memory contents from the server to the client and from the client to the server. This bug left a large number of private keys and other secrets exposed to the Internet.
What are the new vulnerabilities?
There are two “HIGH” severity vulnerabilities that have been patched in OpenSSL 3.0.7. Earlier both these bugs were rated “CRITICAL”, however considering the limited exploitation scenario and the mitigating factors led to the downgrading of the ratings of the vulnerabilities.
CVE-2022-3602 – Buffer Overflow | Remote Code Execution (RCE)
The initial vulnerability dubbed CVE-2022-3602, is a remote code execution vulnerability which can allow attackers to corrupt 4 bytes on the stack. This can be triggered due to incorrect Punycode handling in the X.509 certificate verification, specifically in name constraint checking. Punycode is a representation of Unicode with the limited ASCII character subset used for Internet hostnames. For example, münchen.com (German name for Munich) is encoded as xn--mnchen-3ya.com.
The vulnerable function ossl_punycode_decode() may cause overflow during the Punycode string decoding. This is only possible 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.
Exploitation
To exploit this, an attacker will need to craft a CA/Intermediary certificate that contains a malicious Punycode string in the “nameConstraints” field of at least 516 bytes (including the xn-- part of the Punycode representation). This would overflow the stack and allow attacker controlled payloads to be overwritten on the victim stack resulting in code execution.
However, the likelihood of the exploitation is low due to the following reasons:
- The attacker will have a very limited number of commands available to execute since this vulnerability would only allow overflowing just 4 attacker-controlled bytes on the stack.
- Almost all TLS exchanges involve clients verifying server certificates, and not the other way around.
CVE-2022-3786 – Stack Corruption | Denial of Service
This vulnerability is also related to the buffer overrun that can be triggered in X.509 certificate verification, specifically in name constraint checking, and was discovered while the fix for CVE-2022-3602 was being prepared.
The vulnerable component, in this case, is the ossl_a2ulabel() function which appends “.” to the output when the Punycode representation ends with the “dot” character (ASCII 46, or 0x2E). This leads an attacker to overflow the output buffer with any number of “.” characters, eventually leading to stack corruption. Code execution is not possible since the only character that you can overflow the stack with is the dot. This could lead to crashing of the application.
Exploitation
The nature of exploitation is similar to the previous vulnerability, and the likelihood of exploitation is low since client side authentications involve the server presenting the TLS certificate and the client verifying it. The most probable attack scenario would affect hapless users with unpatched versions visiting a site which presents a malicious certificate resulting in a crash of the user application.
What is affected and what is not?
The affected versions are 3.0.0 through 3.0.6. The vulnerability was patched in v3.0.7. OpenSSL version 1.x is not affected by this vulnerability. Docker confirmed and has come up with a list of images incorporating the vulnerable libraries. Node.js has also confirmed that v17.x, v18.x, and v19.x use OpenSSL v3 and that v18.x and v19.x will be updated to address the security issue. The official security advisory from OpenSSL can be found here.
It is also important to note that Google’s BoringSSL library, Firefox’s Network Security Services (NSS), and OpenBSD’s LibreSSL, all of which provide similar functionality to OpenSSL are all unaffected by these bugs.
The Netherlands’ National Cyber Security Centre has come up with a tremendous effort in gathering operational intel about the vulnerability. This includes a list of softwares utilising the library, IoCs, scanning for the vulnerabilities and much more.
What should you do about it?
Developers and organisations should stay alert and follow critical security practices during times like these. This includes patching and keeping their systems up to date to their latest available versions. Narrowing down a list of softwares affected and determining applications which make use of the vulnerable libraries is crucial to determine which components need to be prioritised while patching.
Determining OpenSSL Versions
System
To find out the current version of the OpenSSL version of your system, the following command can be used:
$ openssl version
Dynamically Linked
For dynamically linked libraries, the versions can be found out using SpookySSLTools’ scanner for Linux and Windows operating systems.
Statically Linked
For statically compiled binaries, a combination of the Linux utilities strings and grep can be used in the following way:
$ strings /path/to/executable | grep -iP "^openssl\s*[0-9].[0-9]"
For Windows systems, few PowerShell utilities can be combined to figure out the version:
$ Select-String -Path C:\path\to\executable.exe -Pattern “openssl\s*[0-9].[0-9]” -AllMatches
Conclusion
The nature of any vulnerability being high-severity in nature usually triggers chaos in the developer and security community. It is important that such vulnerabilities are patched as soon as possible and updates are applied as quickly as possible in a solid strategy for reducing risk and avoiding breaches.
