OpenSSL 3.0.0–3.0.6 vulnerabilities: Less Heartbleed, more paper cut

Invicti’s Chief Technology Officer and Head of Security Research, Frank Catucci, co-authored this article.

Invicti has assessed the risk to its hosted products Invicti Enterprise (formerly Netsparker) and Acunetix Online Premium and determined that there is no risk of exploit. We have proactively upgraded edge systems using OpenSSL 3.0.6 to the patched OpenSSL 3.0.7.

Two principles continually drive our work helping you protect software: Think as attackers do, and aim for zero noise. Not everything’s a catastrophe; if you can’t prioritize, you’ll be more vulnerable, not less. The October 25 announcement of two new OpenSSL vulnerabilities offers a perfect example of what we mean. Is this the next Heartbleed? 

No. 

We’ll show you why, by approaching these vulnerabilities as an attacker would. The technical detail is important, but the takeaway is dead simple. Patch this with OpenSSL 3.0.7. You’ll be a bit safer. The world will be, too. But don’t spend one minute panicking. This one’s not worth a freakout – either by you or by your security systems.

Stepping back: What happened in OpenSSL

A quick refresher if you’ve been away: On October 25, OpenSSL notified users that it had found two new vulnerabilities in OpenSSL 3.0.0 through 3.0.6. One of these was apparently “critical” – the same level as the notorious 2014 Heartbleed flaw. That captured everyone’s attention because Heartbleed affected many high-profile organizations, could compromise encrypted information of all kinds, and actually showed up in the wild. It was bad.

But by November 1, when OpenSSL released its version 3.0.7 fix, it more clearly understood the two new vulnerabilities and downgraded them to “high” severity (see advisory and blog post). Since we’re in the business of scanning servers, applications and APIs for vulnerabilities, we can add value by illuminating why this was done, with a focus on how attackers might try to exploit these flaws – and why they probably can’t.

What to know first about the OpenSSL vulnerabilities

The first new vulnerability, CVE-2022-3602, is an X.509 Email Address 4-byte Buffer Overflow that can be triggered as name constraints are checked during X.509 certificate verification. It only occurs after certificate chain signature verification. Moreover, it requires either a trusted certificate authority (CA) to have signed the malicious certificate or for the application to continue certificate verification even after it’s failed to construct a path to a trusted issuer.

These conditions are uncommon. A CA would have had to sign a malicious certificate or the request would need to be accepted without verification. If that had happened, you’d be at risk even without these vulnerabilities.

As OpenSSL notes, an attacker could craft a malicious email address to overflow four attacker-controlled bytes on the stack. This buffer overflow could cause a crash (hence, denial of service) or, potentially, remote code execution (RCE). But no current exploit can leverage such an RCE.

The second new vulnerability, CVE-2022-3786, is also an X.509 Email Address Variable Length Buffer Overflow with similar characteristics. But this one can’t cause an RCE condition.

What an exploit would require

To see why we’re not too worried, it helps to understand how OpenSSL implements the SSL/TLS handshake and what it would take to make a successful exploit.

Figure 1 shows a typical certificate request and verification sequence. Before a secure connection is established, an SSL/TLS handshake takes place to authenticate and negotiate among the protocol versions and ciphers that the connection will use. After the client provides its certificate, the server verifies that:

• The digital signature is trustworthy.
• The timestamp is valid.
• The certificate is valid and not revoked.
• Certificate Transparency is correctly logged.

This is where the OpenSSL vulnerabilities might cause trouble, utilizing a hostile payload in an email address that is embedded within the client certificate and crafted in international characters encoded in Punycode. But this flow is only used when the SSL/TLS server is configured to request client certificates, which is rare in public internet sites. (The rare optional sequence where these vulnerabilities apply is shown surrounded by dashed red lines.) For an exhaustive analysis of how such a 4-byte stack overflow could work, see here. More importantly for our purposes, here are three reasons most attackers will find this vector problematic: 

1. Getting a CA to sign a malicious certificate isn’t easy or risk-free. Multiple validation steps are required. This is sufficiently non-trivial that hackers would be more likely to attack the CA directly to sign the certificate on their behalf.
2. It can be hard to find a target site for an exploit that requests certificates only from the CA that’s willing to sign your malicious certificate. Many organizations use multiple CAs: you could encounter one you haven’t compromised.
3. Quite simply, it’s hard to formulate a successful attack that exploits these vulnerabilities. And, even if the above two conditions can somehow be met… 

4-byte stack overflows aren’t what they used to be

Even if an attacker overcomes all the other challenges, they can only write a single 4-byte value to the stack. Back in the day (we’re talking the 1990s) four bytes was often enough to overwrite a return pointer on a stack and execute arbitrary code. But not now. Let’s consider why.

The Wikipedia image below shows how a buffer overflow can influence the code a compromised program executes. The attack relies on a buffer allocated on the stack adjacent to the return pointer. It specifies what’ll be executed when a program returns from calling a function. When a programmer doesn’t check the length of untrusted inputs, or makes an “off-by-one” error, an attacker can theoretically divert that next step.

However, this is much harder with modern software stacks. Take, for instance, Ubuntu 22.04, which ships OpenSSL 3.0.6. Ubuntu’s recent Security Advisory discusses how it uses stack protection to help mitigate buffer overflows.

With stack protection, a “canary,” or guard value, is written in memory right before the return pointer. It’s initialized to a random value before the function is invoked, and verified when the function returns. If it’s compromised, that’s an early warning of tampering with the return address – like the classic canary in a coal mine. Seeing that, the program terminates rather than giving the attacker control.

Another technique, Address Space Layout Randomization (ASLR), changes the memory layout of the stack at program launch. Attacks that attempt to jump into a compromised region of memory become far harder because attackers can’t rely on fixed positions in shell code.

Finally, as OpenSSL reported in its blog post, there’s yet another big obstacle to weaponizing these two OpenSSL vulnerabilities. Linux vendors who’ve analyzed them found that the four bytes an attacker could influence are in a “dead region” of the stack that isn’t in use, and can’t influence the program counter.

When attackers consider all these obstacles, most will probably turn elsewhere. That’s why we think it made sense for OpenSSL to downgrade these vulnerabilities from “critical” to “high.”

The bottom line (and what to do)

These are legit bugs, found by talented researchers who deserve our appreciation. Remarkably, OpenSSL had to change only one character to fix CVE-2022-3602 – and by tweaking that “equals sign” in OpenSSL 3.0.7, they’ve made the world a little more secure. So: Scan with SCA to identify instances of OpenSSL 3.0.0–3.0.6 in your code base, and upgrade to 3.0.7 as soon as you can. If you obtain OpenSSL from your OS vendor or another third party, seek updates from them as well. No panic. No flurry of unnecessary red alerts. Just, as embroiderers and security professionals are known to say, keep calm and patch on.

—

1. Essich, CC BY 3.0 https://creativecommons.org/licenses/by/3.0, via Wikimedia Commons