As preannounced, OpenSSL released version 3.0.7, which patches two related vulnerabilities rated as "High." Initially, as part of a preannouncement, the vulnerability was rated "Critical." OpenSSL 3.0 was initially released in September of last year.

The update patches a buffer overrun vulnerability that happens during the certificate verification. The certificated needs to contain a malicious Punycode encoded name, and the vulnerability is only triggered AFTER the certificate chain is verified. An attacker first needs to be able to have a malicious certificate signed by a certificate authority the client trusts. This does not appear to be exploitable against servers. For servers, this may be exploitable if the server requests a certificate from the client (mTLS) [1] . OpenSSL also published a blog post with details here: https://www.openssl.org/blog/blog/2022/11/01/email-address-overflows/

In short: While this is a potential remote code execution vulnerability, the requirements to trigger the vulnerability are not trivial, and I do not see this as a "Heartbleed Emergency". Patch quickly as updated packages become available, but beyond this, no immediate action is needed.

A technical breakdown of the vulnerability, including a demo/PoC that causes a DoS has been made available by DataDog Security Labs  [2].

Punycode is a method to express non-ASCII characters in domain names. As DNS (hostnames and email addresses inside certificates) have to use ASCII-only characters, Punycode was introduced to encode non-ASCII characters. The encoding is not trivial. Punycode domain names start with "xn--" followed by the English characters, another dash, and finally, the non-ASCII characters encoded as ASCII characters. For example, the Punycode domain "xn--govindex-634g.biz" would be displayed as "gov/index.biz" in browsers. "634g" represents the / character and the location where it will be inserted.

Any operating system or software released after that may include a vulnerable version of OpenSSL. Note that software may install its own SSL/TLS library even if the operating system does not include OpenSSL. A good example is MacOS. macOS, by default, uses LibreSSL. But, for example, packages installed via MacPorts or HomeBrew may install OpenSSL. Another example is Node. Node 18, released in April, does include OpenSSL 3.0.

Current versions of OpenSSL 3.0 and 1.1.1 support identical cipher suites and digests/ciphers. Passive fingerprinting may be possible, but it isn't easy. Standard fingerprinting techniques are affected by how applications use either library and are often a better indicator for the application vs. the library version.

Currently, there are two production versions of OpenSSL available:

• OpenSSL 1.1.1 - not vulnerable, supported until Sept. 11th, 2023. Latest version: 1.1.1s 
• OpenSSL 3.0.x - vulnerable if x < 7, supported until Sept. 7th, 2026. The latest version is 3.0.7 (note that 3.0.6 was released but removed quickly after it was released due to a bug)
• OpenSSL 3.1 - not available yet.

The fastest way to figure out what version of OpenSSL you are running is to type

openssl version

We do have our list of vulnerable/not vulnerable Linux distributions here. Or check out this list by the Dutch National Cyber Security Centrum (NCSC-NL).

[1] https://www.openssl.org/news/secadv/20221101.txt
[2] https://securitylabs.datadoghq.com/articles/openssl-november-1-vulnerabilities/

---
Johannes B. Ullrich, Ph.D. , Dean of Research, SANS.edu
Twitter|