CVE-2023-0286: The OpenSSL Who Cried “Severity: High”

By Mark Bereza · February 9, 2023
This story was also written by John Dunlap.

Background

It feels like just yesterday that OpenSSL was the subject of widespread scrutiny over two buffer overflow vulnerabilities rated Severity: High. Fortunately, both vulnerabilities turned out to be technically impressive but less than salient in the real world, due to a combination of limited threat surface and various mitigating factors complicating attempts to exploit memory corruptions on modern systems.

Just a few short months since then, and it seems that we’re back in the same predicament: OpenSSL’s latest security advisory enumerates various vulnerabilities that have been patched in the latest release (3.0.8), some of which were reported as far back as November. Topping the list is CVE-2023-0286, being the only vulnerability in the advisory to be ranked Severity: High. Will this vulnerability actually be the next Heartbleed, like many suspected of CVE-2022-3602 and CVE-2022-3786 before they turned out to be largely toothless?

What is it?

Put simply, CVE-2023-0286 is a type confusion vulnerability that is exercised when OpenSSL processes X.509 GeneralNames containing X.400 addresses. For those not well acquainted with the data formats utilized in certificate processing, all you really need to know is an X.400 address is basically a mailing address but for online data, and a GeneralName is a catch-all data type that can refer to anything from an IP address to a DNS name to even an X.400 address. X.400 and X.509 are simply different standards that define these terms, along with many others utilized in popular cryptography services like public key certificates and digital signatures.

Since a GeneralName can contain all sorts of different data, OpenSSL performs checks when it has to process one to ensure it is handled correctly. Unfortunately, in the case that OpenSSL processes a GeneralName that contains an X.400 address, it stores the underlying address in the wrong data type, using an ASN1_TYPE instead of an ASN1_STRING, resulting in an archetypical type confusion vulnerability. Specifically, this flaw is exposed when OpenSSL performs certificate revocation list (CRL) validation during certificate processing. During this process, it is possible for two X.400 addresses to be compared using the memcmp C function. Due to the difference in memory layout between the ASN1_TYPE and ASN1_STRING structs, it is possible for attackers to specify an arbitrary memory address to be supplied to memcmp. This then leads to comparisons against memory specified by the attacker, potentially allowing for the disclosure of memory contents and denial of service.

Is there actually a wolf this time?

In short, no. This vulnerability comes with a litany of prerequisites and mitigating factors that limit its usefulness to attackers.

First, the vulnerable code path can only be reached during CRL checking (when a server checks a provided certificate against the CRL to verify that it hasn’t been revoked), which requires that CRL checking is enabled via the X509_V_FLAG_CRL_CHECK flag.

While this alone is not uncommon, the second requirement is that both of the two GeneralNames supplied to the memcmp function contain at least one CRL distribution point in the format of an X.400 address. While a CRL defines which certificates are no longer valid, its distribution point defines where to find it in the first place – usually in the form of an LDAP directory or the address of a web server. The relevant point is that it is exceedingly uncommon for this location to be encoded as an X.400 address, meaning this vector is only viable if the attacker controls both inputs: the certificate and the CRL. But this simply trades one implausible scenario for another, as its also uncommon for applications to be configured to utilize third-party CRLs and retrieve them over the network.

Even if an attacker manages to get all these conditions to line up, executing the attack itself poses another challenge, as it would require the vulnerable application to download the certificate and CRL in real-time. According to Red Hat, this is “hardly possible because it implies a separate HTTP request during the TLS connection establishing.” Finally, while data exfiltration is indeed possible, it is far from an arbitrary read primitive, as the only feedback the attacker gets is whether their guess is correct (and how long it took the server to determine their guess was wrong, though this is less than reliable). Put plainly, this is a very, very slow method of data exfiltration. Perhaps the most impactful application of such an attack would be to find small but sensitive data with known keywords or prefixes, such as “BEGIN RSA PRIVATE KEY."

So, what should I do?

Although this is no Heartbleed, patching is still highly advised as the impact of over-the-internet data exfiltration represents a substantial risk to most organizations. OpenSSL’s advisory states that OpenSSL versions 1.02, 1.1.1, and 3.0 are all vulnerable, so if your organization runs any of those it’s time to update to versions 1.0.2zg, 1.1.1t, and 3.0.8, respectively.

The issue was fixed in OpenSSL by altering the erroneous use of the ASN1_TYPE structure to the correct ASN1_STRING structure in the context of GeneralNames.

Figure 1: Thankfully, fixing the vulnerability turned out to be much simpler than exploiting it.

The patch can be found on GitHub here. Trellix’s Advanced Research Center has vetted the relevant source code and corroborate OpenSSL’s claim that this addresses the vulnerable code path.

Those unable to patch can mitigate the vulnerability by disabling X509_V_FLAG_CRL_CHECK, though this has its own share of problems as it will disable checking certificates against a CRL entirely, creating a whole new security risk.

_ This document and the information contained herein describes computer security research for educational purposes only and the convenience of Trellix customers. _