The OpenSSL Project announced on October 25 2022 that one of the two vulnerabilities discovered in the OpenSSL library/toolkit was a critical one. The CVEs and patch releases indicate that the vulnerability (CVE-2022-3602) is far from being as severe. The only other critical vulnerability discovered in OpenSSL since 2014’s Heartbleed Bug.
The CVE-2022-3602 vulnerability is a flaw in the OpenSSL library. It could allow an attacker to insert malicious code into a TLS connection. This could allow the attacker to intercept and tamper with communications between a client and a server. The OpenSSL Project has released a patch to address this vulnerability.
While this vulnerability is serious, it is not as severe as the Heartbleed Bug. That bug allowed attackers to gain access to sensitive information from a server’s memory. The OpenSSL Project has released patches for both vulnerabilities. They also advise users to update to the latest version of the library as soon as possible.
OpenSSL is an open-source software library that provides cryptographic protocols and utilities for secure communications over computer networks. Many web applications and services utilize it to provide secure communication. It is also a major component of the Internet security infrastructure.
It implements the Transport Layer Security (TLS) and Secure Sockets Layer (SSL) protocols to provide encrypted communication and secure data transfer. OpenSSL also provides a general-purpose cryptography library that supports a wide range of cryptographic algorithms and protocols.
OpenSSL is freely available under an open-source license. Visit the OpenSSL website, and it is available for use on a wide range of operating systems.
Two recently discovered vulnerabilities in OpenSSL are exploitable to cause a buffer overrun or potentially execute arbitrary code. However, these vulnerabilities are not as severe as they could be, due to the limited adoption of OpenSSL 3.0 and the fact that no working exploits are currently available.
These vulnerabilities exist in the X.509 certificate verification code, specifically in the name constraint checking. The exploit can be triggered by a specially crafted email address, but it must be signed by a certificate authority (CA) or the application must continue to verify despite not being able to construct a path to a trusted issuer for it to be effective.
Since OpenSSL 3.0 was only released 14 months ago, it is not yet widely adopted, and upgrading from the previous version (1.1.1) is significant. This means that the majority of products are not yet using the latest version of OpenSSL, which reduces the impact of these vulnerabilities.
There are working proofs-of-concept (PoCs) that can cause OpenSSL to crash, but they do not currently lead to remote code execution (RCE).
According to researcher Kevin Beaumont, the OpenSSL vulnerabilities do not look like a big deal. Most default config Linux distributions have stack overflow protections that automatically mitigate code execution. He further added, ”As always, assess and proceed calmly through your usual vulnerability management process.”
These two vulnerabilities in OpenSSL are not as severe as they could be, due to the limited adoption of OpenSSL 3.0 and the fact that no working exploits are currently available. The best way to mitigate these vulnerabilities is to update to OpenSSL version 3.0.7.