At first, it looked like the OpenSSL 3.x security bug was going to be truly awful. While it was feared to be a critical error that could lead to remote code execution (RCE), upon a closer examination it turned out to be not so horrid after all.
Open Source
That’s not to say it isn’t bad. Both CVE-2022-3786 (“X.509 Email Address Variable Length Buffer Overflow”) and CVE-2022-3602 (“X.509 Email Address 4-byte Buffer Overflow”) have a CVE rating of 8.8, which is considered “high.” That means they could still cause you real trouble.
If that is, you’re using OpenSSL 3.0.0 to 3.0.6. OpenSSL 1.1.1 and 1.0.2 users don’t have to worry. However, just because your main operating system uses OpenSSL 1.x, don’t think you can ignore these issues. Your applications or containers may use a vulnerable version. In short, before kicking your shoes off and taking a nap, check your code.
Specifically, you need to worry with 3786 about a buffer overrun that can be triggered in X.509 certificate verification. Here, an attacker can craft a malicious email address to overflow four attacker-controlled bytes on the stack. This could cause a system crash or RCEs.
With 3602, your concern is that a stack-based buffer overflow was found in the way OpenSSL processes X.509 certificates with a specially crafted email address field. Again, this could cause a crash or an RCE.
The most common way where either could be triggered is when a server requests client authentication after a malicious client connects or when a client connects to a malicious server. To date, there have been no successful attacks.
Brian Fox, co-founder and CTO of Sonatype, a software supply chain security company, notes, “While memory overflow bugs can lead to worst-case scenarios, the details of this particular vulnerability seem to indicate that the level of difficulty for an exploit is very high. The vulnerability requires a malformed certificate that is trusted or signed by a naming authority. That means that authorities should be able to quickly prevent certificates designed to target this vulnerability from being created, further limiting the scope.”
Why wasn’t this as big a deal as we first feared? The vulnerabilities are no longer considered critical because many modern operating systems aren’t as vulnerable to their particular security holes.
That’s because an exploited memory stack only overwrites an unused adjacent buffer on some Linux distros, such as Red Hat Enterprise Linux (RHEL). In addition, many modern platforms implement stack overflow protections. Your system may still crash, but it’s not likely that an attacker could pull off an RCE.
But, as the OpenSSL warns, since “OpenSSL is distributed as source code, we have no way of knowing how every platform and compiler combination has arranged the buffers on the stack, and therefore remote code execution may still be possible on some platforms.”
In addition, while the OpenSSL patch is upstream, that doesn’t mean your distribution has the patch ready to go. So, you can’t simply update your Debian Linux family software with…
$ sudo apt-get update
$ sudo apt-get upgrade
…and be certain you’ll be safe. Check with your Linux distributor to make sure the OpenSSL 3.0.7 patch is ready for your system. Or you can always download and compile the patch yourself for your system.
Finally, OpenSSL always recommends using the latest version (1.1.1s) and reminds you that OpenSSL 1.1.1 is only supported until 11th September 2023. Users of older versions of OpenSSL (such as 1.0.2) are encouraged to upgrade to OpenSSL 3.0. Keep in mind, there was never an OpenSSL 2 release. If someone tries to get you to “upgrade” to OpenSSL 2, they’re attacking you.
Before patching and leaving this problem behind, Chainguard and Sigstore founder Dan Lorenc would like you to remember that even if it had turned out to be a critical OpenSSL vulnerability, “it was only the second one in the better part of a decade. This reinforces that open-source code is at least as secure as proprietary, closed-source code. … Instead of debating the merits of open source, we should instead focus on building secure software that has the tooling necessary to make remediation faster and more seamless by rooting in secure by default measures.”
Related Stories:
