OpenSSL has published a security advisory about two buffer overflow vulnerabilities with a severity rating of “High.” The rating came as a bit of a surprise, since one of them was announced a week earlier as “Critical.”

A buffer overflow is a type of software vulnerability that exists when an area of memory within a software application reaches its address boundary and writes into an adjacent memory region. In software exploit code, two common areas that are targeted for overflows are the stack and the heap.

Currently supported versions

The latest stable version is the 3.0 series supported until September 7, 2026. This is also a Long Term Support (LTS) version. The previous LTS version (the 1.1.1 series) is also available and is supported until September 11, 2023. All older versions (including 1.1.0, 1.0.2, 1.0.0 and 0.9.8) are now out of support and should not be used.

All good news

The security advisory may come as a disappointment to some criminals, but for everyone else this is good news all around. The patch for the two vulnerabilities is now available. The announced vulnerability wasn’t as severe as we expected. And there is no known exploit for the vulnerabilities doing the rounds.

Cloudflare says it’s not affected by the OpenSSL vulnerabilities. It explained that the vulnerabilities reside in the code responsible for X.509 certificate verification—most often executed on the client side to authenticate the server and the certificate presented.

“In order to be impacted by this vulnerability the victim (client or server) needs a few conditions to be true:

• A malicious certificate needs to be signed by a Certificate Authority that the victim trusts.
• The victim needs to validate the malicious certificate or ignore a series of warnings from the browser.
• The victim needs to be running OpenSSL 3.0.x before 3.0.7.

For a client to be affected by this vulnerability, they would have to visit a malicious site that presents a certificate containing an exploit payload. In addition, this malicious certificate would have to be signed by a trusted certificate authority (CA).”

The vulnerabilities

CVE-2022-3602: A buffer overrun can be triggered in X.509 certificate verification, specifically in name constraint checking. Note that this occurs 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. An attacker can craft a malicious email address to overflow four attacker-controlled bytes on the stack. This buffer overflow could result in a crash (causing a denial of service) or potentially remote code execution.

Many platforms implement stack overflow protections which would mitigate against the risk of remote code execution. The risk may be further mitigated based on stack layout for any given platform/compiler.

Pre-announcements of CVE-2022-3602 described this issue as CRITICAL. Further analysis based on some of the mitigating factors described above have led this to be downgraded to HIGH. Users are still encouraged to upgrade to a new version as soon as possible.

CVE-2022-3786: A buffer overrun can be triggered in X.509 certificate verification, specifically in name constraint checking. Note that this occurs after certificate chain signature verification and requires either a CA to have signed a malicious certificate or for an application to continue certificate verification despite failure to construct a path to a trusted issuer. An attacker can craft a malicious email address in a certificate to overflow an arbitrary number of bytes containing the `.’ character (decimal 46) on the stack. This buffer overflow could result in a crash (causing a denial of service). In a TLS client, this can be triggered by connecting to a malicious server. In a TLS server, this can be triggered if the server requests client authentication and a malicious client connects.

OpenSSL versions 3.0.0 to 3.0.6 are vulnerable to these issues, so OpenSSL 3.0 users should upgrade to OpenSSL 3.0.7.

Checklists

If you are wondering whether your organization needs to worry about this update, there are a few public efforts that can help you make that assessment.

Pierre-Olivier Blu-Mocaer has created a crowdsourced list of software using OpenSSL version 3, on GitHub.

The Dutch NCSC built a list of software products which are known to be affected by this OpenSSL vulnerability or not.

Akamai has shared OSQuery and YARA rules to help organizations find vulnerable assets.