An Overview of the OpenSSL 3.0 Critical Vulnerability & Memory Safety

If you're one of the millions of people who use OpenSSL, then you must've heard (and panicked) when news broke last year of a critical vulnerability in the widely used encryption software. 

In this blog, we're discussing the critical vulnerability that impacted the OpenSSL3.0 version. And if you stick around to the end, we'll also share some safer alternatives for your encryption needs.

What is OpenSSL?

SSL certificates are commonly used to secure web sites by establishing an encrypted connection between the client and the server. When you visit a secure site, you'll see the lock icon in your browser and the site address will begin with https:// instead of http://. This indicates that the connection is secure and that the information you send to the site is encrypted and protected from eavesdropping. 

While earlier, SSL certificates were not that popular, today they are in huge demand and have become the standard for securing online websites. Most countries have over 90% of their online traffic encrypted, and the majority of enterprises use SSL certificates. As more people use the internet and cybercrime increases, having an SSL certificate for your website is no longer an option, but a requirement.

OpenSSL is an open source cryptography library that makes it possible to create and manage SSL certificates for websites. As an open source project, the code is freely available and can be used by anyone. It also provides encryption, authentication, and other security features for the internet, including support for multiple algorithms, algorithms for digital signatures and encryption, as well as an API for developing secure applications. It is available for Windows and Linux operating systems and supports numerous different cryptographic algorithms.

What is the OpenSSL3.0 Critical Vulnerability?

The first critical vulnerability that surfaced in OpenSSL was the Heartbleed vulnerability, which was discovered in April 2014. The Heartbleed vulnerability was a severe flaw in the Heartbeat extension in OpenSSL and allowed attackers to transmit apparently valid communications that might trick a computer into leaking confidential information such as passwords and payment details.

At the time of its discovery, Heartbleed caused mayhem and compromised nearly two-thirds of the internet, exposing the personal and confidential records of countless users. It was going to go down in history as one of the most devastating vulnerabilities. 

In October 2022, OpenSSL found itself in the news again when it was announced that another critical vulnerability had been found in the popular open source project. This vulnerability was the highest severity vulnerability found in OpenSSL since Heartbleed. 

A week after its discovery, its severity was downgraded to 'high' and it was split into two CVEs, known as CVE-2022-37786 (X.509 Email Address Variable Length Buffer Overflow) and CVE-2022-3602 (X.509 Email Address 4-byte Buffer Overflow). 

Both the vulnerabilities could trigger a buffer overflow in the X.509 digital certificate verification, specifically in name constraint checking.  However, this would only be possible if the attacker was able to trick a certificate authority into signing a malicious certificate. Moreover, the vulnerabilities did not affect all versions of OpenSSL. It only affected OpenSSL version 3.0-3.6. The buffer overflow could lead to a crash which could then allow the attacker to launch a DDoS attack. You can find more information about these security flaws here. 

Fortunately, these vulnerabilities were patched quickly and no critical data was compromised. Although these vulnerabilities were not as severe as Heartbleed, they still served as a reminder of how crucial it is to keep OpenSSL up to date to protect against security vulnerabilities.

What is Memory Safety and Why is it Important?

So the question that remains is - is patching the OpenSSL critical vulnerability enough or should you be more concerned? 

The two vulnerabilities despite being rated only 'high' and not that likely to be exploited still stand as a threat to your website. And it's not to say that vulnerabilities like these won't come up again. 

Patching the critical vulnerabilities is the most effective way to protect against the OpenSSL critical vulnerability. However, is there a way to mitigate the risk of this type of vulnerability in the future? 

Both the critical OpenSSL vulnerabilities were memory safety issues. Memory safety is a property of computer programs which ensures that they are robust against certain types of vulnerabilities that arise from the way memory is used. 

The fundamental drawback of OpenSSL is that it is written in C and as a result can be more susceptible to memory safety bugs. Memory safety bugs are particularly common in C, C++, and assembly.

Languages that are not memory safe allow users to steal data from previous users, and even access memory that has been deleted by the user. These are fundamental security gaps that can leave your website vulnerable to attacks. 

If you think that memory safety issues are not that common and you don't need to be worried, think again. As of 2022, memory safety bugs were responsible for more than 60% of high severity security vulnerabilities and millions of user-visible crashes. 

Remember Heartbleed? That was a memory safety bug. So was the infamous WannaCry exploit. 

So, does that mean that you can never use open source software again? No. 

But why use one that could be more susceptible to bugs? Especially when there are other tools that are written in safer languages and still provide the same level of security and performance. 

Rusttls is an open source TLS implementation that has been gaining popularity over the last few years. It's written in the Rust programming language and is a memory-safe alternative to OpenSSL. Another such alternative is Mesalink that is also written in Rust. Swift and Go are also memory safe options. 

But keep in mind that these solutions are not magically bullet-proof. Vulnerabilities arise in every program and you might encounter new challenges with these solutions too. Especially since migrating to a new language can be a significant undertaking. However, they give you the opportunity to completely avoid the most common bugs that plague OpenSSL. And it's time we use memory safe solutions for security sensitive data. Wouldn't you rather work harder with a safer, newer tool than simply use a buggy one?

Conclusion

So there you have it, a brief summary of the critical vulnerabilities of OpenSSL3.0 (were not as dangerous as everyone anticipated they would be) and a couple of alternatives to consider. While you may have dodged a bullet with them, it's a good reality check that vulnerabilities like this might strike at any time. We hope you patched OpenSSL if you were affected, and that this serves as a reminder for you to test your systems regularly, patch and update religiously, and move to safer alternatives if you have the opportunity and resources.