Tech

OpenSSL dodges a security bullet


Protect computer systems, secure databases, secure internet.  Lock icon on computer data abstract binary programming, data protection technology.  Vector illustration

Getty Images / iStockphoto

At first it looks like OpenSSL 3.x security bug would be really terrible. While it was feared that this was a fatal bug that could lead to remote code execution (RCE), upon closer inspection it turned out to be not so horrendous.

That doesn’t mean it’s not bad. Both CVE-2022-3786 (“X.509 Email address variable-length buffer overflow”) and CVE-2022-3602 (“Email address X.509 4-byte buffer overflow”) has a CVE rating of 8.8, considered “high”. That means they can still get you in real trouble.

If it is, you are using OpenSSL 3.0.0 to 3.0.6. OpenSSL 1.1.1 and 1.0.2 users need not worry. However, just because your primary OS uses OpenSSL 1.x, don’t think you can ignore these problems. Your applications or containers may use a vulnerable version. In short, before putting on your shoes and taking a nap, test your code.

In particular, you need to worry with 3786 about buffer overflows that can be triggered in X.509 certificate verification. Here, an attacker can create a malicious email address to overflow four attacker-controlled bytes on the stack. This may cause system crashes or RCEs.

With 3602, your concern is a stack-based buffer overflow that was found in the way OpenSSL handles X.509 certificates with specially crafted email address fields. Again, this can cause problems or RCE.

The most common way it can be triggered is when the server requests client authentication after a malicious client connects or when a client connects to a malicious server. To date, no attacks have been successful.

Brian Fox, Co-Founder and CTO of Sonatypea software supply chain security company, notes, “While a memory overflow can lead to worst-case scenarios, the details of this particular vulnerability seem to show just how difficult it is to exploit.” This vulnerability requires a malformed certificate that is trusted or signed by a naming authority which means that the authority can quickly block certificates designed to be targeted target this vulnerability, while limiting its scope further.”

Why isn’t this as big of a deal as we first feared? Vulnerabilities are no longer considered serious because many modern operating systems are not vulnerable to their specific vulnerabilities.

That’s because the memory stack being exploited just overwrites an unused contiguous buffer on some Linux distributions, such as Red Hat Enterprise Linux (RHEL). Additionally, many modern platforms implement protections against stack overflow. Your system may still crash, but it’s unlikely that an attacker can get the RCE.

However, as OpenSSL warns, since “OpenSSL is distributed as source code, we have no way of knowing how every platform and combination of compilers has arranged the buffers on the stack, and so that can still execute code remotely on some platforms.”

Also, while the OpenSSL patch is upstream, that doesn’t mean your distribution is ready to release the patch. So you can’t just update Debian Linux home software with…

$ sudo apt-get update

$ sudo apt-get upgrade

…and make sure you’ll be safe. Check with your Linux distribution 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 September 11, 2023. Users of older OpenSSL versions (such as 1.0.2) are encouraged to upgrade to OpenSSL 3.0. Remember, there was never an OpenSSL 2 release. If someone tries to ask you to “upgrade” to OpenSSL 2, they are attacking you.

Before patching and leaving this problem behind, Chainguard and Sigstore Founder Dan Lorenc wants you to remember that even if it turns out to be a critical OpenSSL vulnerability, “it’s only the second flaw in the better part of a decade. This reinforces that the code is open source at least. just as secure as closed source, proprietary.… Instead of debating the merits of open source, we should instead focus on building secure software that has the tools needed for quick fixes. more and more seamless by rooting in security measures by default.”

But related story:

news7g

News7g: Update the world's latest breaking news online of the day, breaking news, politics, society today, international mainstream news .Updated news 24/7: Entertainment, Sports...at the World everyday world. Hot news, images, video clips that are updated quickly and reliably

Related Articles

Back to top button