Security Vulnerability in OpenSSL CVE-2022-3602 (RCE) and CVE-2022-3786 (DOS)

Earlier today a new Security Vulnerability was disclosed in the popular OpenSSL (libssl) Library (affecting products using OpenSSL 3.0.0-3.0.6.) which affects most software companies in the world. The OpenSSL team released an updated version of the library today 3.0.7.

OpenSSL CVE-2022-3602 (RCE) and CVE-2022-3786 (DOS) published earlier today and was fixed in the release 3.0.7

NOTE: The chances of being able to exploit this vulnerability is really low, since there are a lot of requirements that needs to be in place for someone to be able to successfully exploit it, more details here –> Pwn All The Things on Twitter: “Folks who’ve been up for a while waiting for this “critical” #openssl vulnerability, here it is. Quick thread of initial thoughts https://t.co/XrAm4YAuUo” / Twitter

The updated version is here –> openssl: 3.0.5 -> 3.0.7 by mweinelt · Pull Request #198999 · NixOS/nixpkgs (github.com)

Change Notes:

 * Fixed two buffer overflows in punycode decoding functions.

   A buffer overrun can be triggered in X.509 certificate verification,
   specifically in name constraint checking. Note that this occurs after
   certificate chain signature verification and requires either a CA to
   have signed the malicious certificate or for the application to continue
   certificate verification despite failure to construct a path to a trusted
   issuer.

   In a TLS client, this can be triggered by connecting to a malicious
   server.  In a TLS server, this can be triggered if the server requests
   client authentication and a malicious client connects.

   An attacker can craft a malicious email address to overflow
   an arbitrary number of bytes containing the `.`  character (decimal 46)
   on the stack.  This buffer overflow could result in a crash (causing a
   denial of service).
   ([CVE-2022-3786])

   An attacker can craft a malicious email address to overflow four
   attacker-controlled bytes on the stack.  This buffer overflow could
   result in a crash (causing a denial of service) or potentially remote code
   execution depending on stack layout for any given platform/compiler.
   ([CVE-2022-3602])

Most Linux distros these days are bundled with the affected versions.
Distros avec OpenSSL 3.0 installé par défaut

How severe is the vulnerability?

The information about the vulnerability came out today (Spooky SSL) and it affects a smaller set of machines. Akamai did some tests on their managed networks and saw

  • ~50% of monitored environments had at least one machine with at least one process that depends on a vulnerable version of OpenSSL.
  • Of those networks, the percentage of machines in the network that had some dependence on a vulnerable OpenSSL version ranged from 0.2% to 33%.
    • Median coverage was 6.1%, mean was 11.3% with standard deviation of 11.6%.

There is limited information about which vendors and products are affected, but there is an unofficial list here –> https://lnkd.in/dQweeCu8

This website also contains different methods to verify the presence of the OpenSSL product is installed in your environment as well.

It also shows what kind of tools and scripts can be used to detect if you have the affected version within your environment.

Why is it predominantly Linux software that is affected? Windows has another SSL library called SChannel which is not affected by this vulnerability. However, Windows can also have the library installed. OpenSSL is used in software like VMware tools which is installed on most machines running on VMware.

To remove the vulnerability for products like VMware you have to wait for them to provide an update to their product.

Leave a Reply

Scroll to Top