shorts

Critical vulnerabilities in OpenSSL 3.0

figure
Nov 11, 2022
Sergey Chernyshev

The OpenSSL Project released a Security Advisory on November 1, 2022, concerning two critical vulnerabilities discovered in the OpenSSL library versions 3.0.0 to 3.0.6. OpenJDK distributions, including Liberica JDK, use their own implementation of TLS and therefore are not affected. But OpenSSL is a very popular library, and is very likely implemented in the software you are using in your project. So read on to find more about the risks and possible solutions.

What is the issue?

Both vulnerabilities were assigned a High severity level. Both can be triggered during a client’s or server's validation of an X.509 certificate.

With the first one, X.509 Email Address 4-byte Buffer Overflow (CVE-2022-3602), a specifically crafted email address can overflow four attacker-controlled bytes on the stack. In the case of the second vulnerability, X.509 Email Address Variable Length Buffer Overflow (CVE-2022-3786), a buffer overflow can be caused by a malicious email address abusing an arbitrary number of bytes containing the “.” character (decimal 46) on the stack. The CVEs’ exploitation may lead to denial of service (DoS) or remote code execution (RCE).

Both CVEs can be triggered if a vulnerable TLS client connects to a malicious server or a vulnerable TLS server requests client authentication and a malicious client connects.

What should you do?

The CVEs were patched in version 3.0.7. If you are using OpenSSL 3.0, you should upgrade to the newest library version as soon as possible: this is the only way to deal with CVE-2022-3602. In the case of CVE-2022-3786, you can temporarily disable the verification of client certificates.

Library versions 1.1.1 and 1.0.2 are not affected by the issue. If the library is bundled with the third-party software you are using, you should update the software as soon as the patch becomes available. This is also the case with operating systems with OpenSSL installed (Ubuntu 22.04, CentOS Stream 9, Alpine Edge, etc.). Also, Amazon Linux 1 and Amazon Linux 2 don’t ship with OpenSSL 3.0, so no patch is required. As far as Alpine Linux is concerned, the patch is already available. And of course we keep BelSoft software safe. If you are using our containers based on Liberica JDK and these distributions, you don’t have to worry because they do not include this library by default. To keep Alpaquita Linux secure, we have already updated its OpenSSL package. You can find the patched version in Alpaquita's repositories.

Conclusion

Keeping to the latest software version helps to guard against CVEs and other issues. To find out more about previous critical vulnerabilities in outdated security protocols, read our article End of life for old TLS. Stay safe!

Further reading

Want to integrate continuous monitoring of security issues? Consider using vulnerability scanners for Java apps

Curious to know about the most dangerous vulnerabilities patched in newer versions of TLS? Read about the CVEs hidden in outdated versions of the security protocol

Eager to enhance the security of your Linux distribution for cloud and server? Discover tips and recommendations on hardening Linux security

posts
Alpaquita vs Alpine: a head-to-head comparison
figure
Nov 10, 2022
Dmitry Chuyko
shorts
Critical vulnerabilities in OpenSSL 3.0
Nov 11, 2022
Sergey Chernyshev

Find out about the newest CVEs discovered in OpenSSL 3.0 and how to eliminate the risk of exploits

Subcribe to our newsletter

figure

Read the industry news, receive solutions to your problems, and find the ways to save money.