November, 08 2022

Update now to defend against openssl 3.x vulnerability

A corrective release of the OpenSSL 3.0.7 cryptographic library has been published, fixing two vulnerabilities. Both issues are caused by a buffer overflow in the code for validating the email address field in X.509 certificates and could potentially lead to code execution when processing a specially crafted certificate. At the time of the publication of the fix, the OpenSSL developers had not recorded the existence of a working exploit that could lead to the execution of the attacker's code.

Both CVE-2022-3786 and CVE-2022-3602 vulnerabilities are now rated HIGH instead of Critical. Nevertheless, users are encouraged to upgrade to 3.0.7 as soon as possible.

Likelihood of exploitation

Give the fact the vulnerability is primarily client-side, requires the malicious certificate to be signed by a trusted CA (or the user to ignore the warning), and is complex to exploit, I estimate a low chance of seeing in-the-wild exploitation.

Please note OpenSSL 3  vulnerability exists only in OpenSSL Version 3 and not SSLv3, which must be disabled, as it is not secure anymore.

The vulnerability affects only OpenSSL version 3.0.0 to 3.0.6, with the patch being shipped in version 3.0.7. Due to the fact OpenSSL 3.0.0 was released in September 2021, it is far less widespread than previous versions. Given the very recent release date, older appliances with hardcoded OpenSSL version are unlikely to be vulnerable.

How To check the version

Linux & *Nix Scanner (Bash Script):

Windows scanner (PowerShell):


Although the pre-published announcement of the new release mentioned the presence of a critical issue, in fact, in the released update, the status of the vulnerability was reduced to a dangerous, but not a critical vulnerability. In accordance with the rules adopted in the project, the severity level is reduced in case of a problem in atypical configurations or in case of a low probability of exploiting a vulnerability in practice.


In this case, the severity level has been reduced because a detailed analysis of the vulnerability by several organizations concluded that the ability to execute code during production is blocked by stack overflow protection mechanisms used in many platforms. In addition, the stack layout used in some Linux distributions causes the overflowing 4 bytes to overlap with the next buffer on the stack, which is not yet in use. However, it is possible that there are platforms that can be exploited to execute code.

Issues identified:


- Initially reported as critical, a vulnerability causes a 4-byte buffer overflow when checking a specially crafted email address field in an X.509 certificate. In a TLS client, the vulnerability can be exploited by connecting to a server controlled by the attacker. On a TLS server, the vulnerability can be exploited if client authentication using certificates is used. In this case, the vulnerability manifests itself at the stage after verification of the chain of trust associated with the certificate, i.e. The attack requires the certification authority to validate the attacker's malicious certificate.


CVE-2022-3786 is another vector of exploitation of the CVE-2022-3602 vulnerability identified during the analysis of the problem. The differences come down to the possibility of a buffer overflow on the stack by an arbitrary number of bytes containing the character "." (i.e. the attacker has no control over the content of the overflow and the problem can only be used to cause the application to crash).

The vulnerabilities appear only in the OpenSSL 3.0.x branch (the bug appeared in the Unicode conversion code (Punycode) added to the 3.0.x branch). OpenSSL 1.1.1 releases, as well as LibreSSL and BoringSSL forks from OpenSSL, are not affected. At the same time, an update to OpenSSL 1.1.1s was generated, which contains only non-security-related bug fixes.

The OpenSSL 3.0 branch is used in distributions such as Ubuntu 22.04, CentOS Stream 9, RHEL 9, OpenMandriva 4.2, Gentoo, Fedora 36, ​​Debian Testing/Unstable. Users of these systems are advised to install updates as soon as possible (Debian, Ubuntu, RHEL, SUSE/openSUSE, Fedora, Arch). In SUSE Linux Enterprise 15 SP4 and openSUSE Leap 15.4 packages with OpenSSL 3.0 are available as an option, system packages use the 1.1.1 branch. Debian 11, Arch Linux, Void Linux, Ubuntu 20.04, Slackware, ALT Linux, RHEL 8, OpenWrt, Alpine Linux 3.16 and FreeBSD remain on the OpenSSL 1.x branches.

It can be assumed that affected Linux distributions and manufacturers of affected software products will provide appropriate security updates soon. The only option for the end user is to wait for such updates from software manufacturers and then install them.