Last updated November 2 to include latest information on this evolving issue.
How it Started:
Last week, OpenSSL.org announced a November 1, 2022 (between 1300 – 1700 UTC) release of OpenSSL version 3.0.7.
At the time of initial announcement, the only information provided was that it was a security-fix release that would address an undisclosed “critical” security vulnerability that affects OpenSSL versions 3.0.x. The message, while brief, was clear – this was an urgent fix.
OpenSSL is one of the most prominent open-source cryptographic libraries in the world. It is used in applications, operating systems, and websites for secure communications, so this vulnerability has the potential to affect nearly every organization. As an aside, this is the second “critical” security issue that OpenSSL has announced (the previous one was in 2016) since the company began publicly reporting.
While little could be gleaned from the company’s original sparse announcement, with the official release now out, we can dive a bit further.
The Good News:
To keep it short and sweet, the good news is it’s not as bad as it was originally thought.
Before the version update and publication of the details on November 1, OpenSSL ranked the vulnerability “critical,” the highest severity rating possible on a security finding based on industry standard metrics. With the cat now out of the bag, researchers from across the globe have started to scrutinize the issue. It turns out it’s not all doom and gloom, and instead of a rolling a “Crit” (for those D&D-playing users), the final risk rating was downgraded to “high” for the two disclosed issues. (See the official release for full details).
Dubbed by the community as “Spooky SSL,” the official CVE classification for this vulnerability was CVE-2022-3602 X.509 Email Address 4-byte Buffer Overflow.
The second disclosed vulnerability in this patch release is CVE-2022-3786 X.509 Email Address Variable Length Buffer Overflow.
TLDR – Just Tell Me What I Should Do:
For those who want to skip ahead, here’s the short version: Achieving Remote Code Execution (RCE) via this vulnerability is difficult, largely because of the already existing stack overflow protection provided by most platforms. Users are still highly encouraged to upgrade to the newest version as soon as possible. If we learned nothing else from our prior Log4j endeavors, it’s that the situation can always evolve with time, but it’s also not quite as bad as we thought.
- If you are running a version of OpenSSL prior to 3.0.0, this flaw currently doesn’t apply to you.
- If you are running a version of OpenSSL 1.1.1 or 1.0.2, you are also in the clear.
- If you are running versions 3.0.0 – 3.0.6, congratulations, this vulnerability is for you! And you should plan your upgrade path to the latest available version, which at the time of writing is version 3.0.7.
- If you’re reading this sometime in the future, you should upgrade to the latest available version.
This vulnerability largely affects developers of products or web resources that leverage OpenSSL, most notably and commonly right now, applications written using Node.js 18.x or newer (pending a fix for the 18.x and 19.x version sets that is planned for release on Nov 3, 2022).
If you are a developer, check your library stack and see if you are using a vulnerable version.
For everyone else that doesn’t have in-house code, you will want to check and see if your OS is vulnerable, particularly if you are using a Linux distro, and validate with software vendors and SaaS providers whether they are vulnerable. A decent and growing list of vendors with a known status can be found on GitHub along with some rudimentary and early-stage scanners and IOCs for detecting vulnerable versions.
An important side note here: OpenSSL is dominantly distributed as source code instead of a compiled binary. This means that due to its open source nature, there can be as many potential variants and modified versions as there are implementations and uses. It’s hard to say that something might not be vulnerable if it’s using the source as part of another piece of software as opposed to some of its pre-compiled standalone forms, as there is no telling what alternations, positive or negative, have been made to the code. So, it’s still worth keeping an eye on it!
I’m Still Here Waiting for the Deets:
For those of you still here reading with me looking for those juicy tech nuggets, I congratulate you on your patience, and I come bearing your desired reward!
Let’s start with our special vuln of the day, CVE-2022-3602 aka Spooky SSL.
Spooky SSL (CVE-2022-3602)
This vulnerability is the result of a flaw in the verification logic used for constraint checking and found to be possible to trigger a buffer overflow during verification of the X.509 certificate.
The vulnerability itself exists in the punycode decoding function (ossl_punycode_decode), a bit of code designed to decode punycode domain names. If you’ve never heard of punycode before, punycode is a representation of Unicode with a limited ASCII character set used for internet hostnames. In some cases (mostly found internationally), a hostname or domain name includes characters that need to be represented in Unicode – for example, the hostname of a Japanese system may include Japanese characters. But not all protocols handle Unicode well. Punycode is the result of encoding these characters into an ASCII representation to be used in circumstances where Unicode would not otherwise be easily or appropriately handled.
As an example, the word for “scary” in Japanese is written as 怖い (read using romaji as “kowai”). In punycode, 怖い would be encoded to “xn--n8ju35l.”
Now that we’ve taken our brief detour to explore what punycode is, how does it relate back to the vulnerability?
Well, dear reader, I’m glad you hypothetically asked!
In our punycode example, we presented a translation for the word “scary” in Japanese. Let’s for a second pretend we have a scary company with the website domain “怖い.com” (using the characters instead of the English word “scary”). This domain would be considered an International Domain Name (IDNA) in Application Domain. The vulnerable function we mentioned earlier (ossl_punycode_decode) is responsible for parsing and processing our IDNA domain so it is compatible with later operations. When the server wants to validate the X.509 certificate, this function is called to validate and decode any IDNA domains present in the certificate. These IDNAs potentially can be found in either the certificate domain field or the email field.
If an attacker were to create a malicious certificate that contains content that needs to be decoded, such as an email or domain name using Unicode characters, the vulnerable function can be triggered and if conditions are met in the underlying system, a 4-byte stack buffer overflow can be achieved with remaining characters. This would cause a crash resulting in denial of service (DoS) in most cases, and potentially the ability to perform remote code execution (RCE). Currently, there is no known working version of this exploit in use in the wild, and given the barriers to entry to leverage it, it would be difficult to execute in a meaningful way at this time. It is worth noting that execution has been achieved in a lab environment, but dominantly resulted in a system crash and DoS condition.
The extra dirty tech details can be found in an excellent writeup by the Datadog Research team, complete with some example code and the vulnerable functions.
OpenSSL is distributed dominantly as source instead of a binary release, so there’s no telling without further investigation how this function has been used or modified in other releases which include the code, or how we can make a good general assumption of exploitation viability.
Our Research Team continues to track emerging news related to this vulnerability. We’ll post updates to this blog as we learn more about the downstream impacts and any new steps that can be taken to eliminate or reduce your exposure.