Critical OpenSSL vulnerabilities: CVE-2022-3602 and CVE-2022-3786

Cybersecurity News Last updated: 06 Jul 2023

A critical vulnerability was discovered in current versions of OpenSSL affecting almost every organization. A fix is now out since 1 November. Learn more about the vulnerabilities and what to do if you have been impacted.

What you need to know

OpenSSL is a software library widely used by companies to enable secure network connections. First released in 1998, it is available for Linux, Windows, macOS, and BSD systems. OpenSSL lets users perform various SSL-related tasks, including Certificate Signing Request (CSR) and private key generation, and SSL certificate installation. So if you’re using HTTPS, chances are you’re using OpenSSL.

The OpenSSL project, the developer of OpenSSL, issued an advisory on Tuesday, October 25th giving advance notice of a security-fix release stating that they consider this issue as CRITICAL affecting OpenSSL versions 3.0 and above. So if you’re using a version lower than 3.0, you are not impacted for the time being. Particular attention should be paid to this incident as this is only the second time in history that the OpenSSL team has announced a critical-rated issue since the introduction of their severity criteria in 2014.

The Open SSL Project defines a critical vulnerability as affecting:

“common configurations and which are also likely to be exploitable. Examples include significant disclosure of the contents of server memory (potentially revealing user details), vulnerabilities which can be easily exploited remotely to compromise server private keys or where remote code execution is considered likely in common situations”

[Update 17:35 CET, 1 Nov] The OpenSSL Project disclosed CVE-2022-3602 and CVE-2022-3786 as high severity vulnerabilities in OpenSSL 3.0 and above. The vulnerability that had originally been categorized as “critical” was split into two vulnerabilities of severity “high”. One of them is a rather boring crash and the other one is “overwrite 4 bytes of memory” which may in some cases lead to RCE. As every 3.x-shipping-distro is by definition modern, it uses modern compilers with mitigations for this as well, turning the “potential RCE” vulnerability into, basically, a crash as well.

What platforms are affected?

As for affected platforms, from what we can tell from the “common” ones, it looks like Alpine >= 3.15, RHEL9/CentOS Stream9, Debian 12, Fedora 36, and Ubuntu 22.xx are the only ones – and they’re all modern enough to have compiler mitigations, leading to this effectively being a crash on those servers.
We are currently awaiting vendor advisories to update to contain more data, rules will be updated as the vendors gather their data.

✅ To date, no Outpost24, and Specops Password Security solutions are currently affected by the vulnerability. We will continue to review and monitor our systems and tools to ensure our services are not impacted. Outpost24 has also released detection rule for unauthenticated and authenticated scans to detect the usage of OpenSSL 3.x.

I’m running Windows, am I safe?

Yes, Windows isn’t vulnerable by default. Of course one could install a vulnerable OpenSSL on Windows which could be common in something like LAMP stacks.

Will there be supply chain implications?

Pretty small but still significant, mainly since OpenSSL 3.x hasn’t been out for long enough for it to seep into every corner of our digital space. Some vendors that may be affected are Fortinet, Broadcom, and VMware. We will keep an eye open for their advisories and update our detection accordingly.

What you should do next

Inform your internal team and developers about the vulnerability announcement and forth-coming security release. Make sure they are ready to patch
Assess your web applications and infrastructure to determine if OpenSSL 3.0 or above is embedded anywhere. The Outpost24 Vulnerability Research Team has released rules which work by comparing OpenSSL versions. This may work unauthenticated in cases where the server actively says what OpenSSL version it’s running, but for reliable checks we suggest running authenticated scans
Update any vulnerable OpenSSL components as soon as the 3.0.7 release is out, prioritizing internet facing and business critical assets with sensitive data