Resource Library
Security BulletinsRiskVisibilityFebruary 15, 2024

ORDR Security Bulletin - OpenSSLv3

November 09, 2022

The OpenSSL Project recently announced CRITICAL vulnerabilities associated with OpenSSL versions 3.0 and higher that include:

CVE-2022-3602 is an arbitrary 4-byte stack buffer overflow that could trigger crashes or lead to remote code execution (RCE).

CVE-2022-3786 can be exploited by attackers via malicious email addresses to trigger a denial-of-service state via a buffer overflow.

These vulnerabilities were later downgraded from CRITICAL to HIGH (CVSS score 8.8 from 9.0). OpenSSL version 3.0.7, released on November 1, 2022, addresses these vulnerabilities. The following document provides important information to understand and protect your assets from these vulnerabilities.

What is OpenSSL?

OpenSSL is a widely used open-source cryptography utility implemented to secure web traffic exchanged between a client and server. It is used to generate public and private keys, install SSL/TLS certificates, verify certificate information, and provide encryption.

Most web servers across the Internet and within intranets use SSL certificates to secure connections and the website being browsed. These certificates are traditionally generated by OpenSSL.

How concerned should you be about this vulnerability?

OpenSSL can be misused if the vulnerable version is in use. The good news is that this vulnerability impacts a very specific version of OpenSSL and patching quickly will address any associated risks.

A flaw in OpenSSL has previously affected businesses. In April 2014, OpenSSL’s Heartbleed flaw was discovered. Numerous web servers, including those running popular websites like Yahoo, included it. Security teams rushed to apply updates because the vulnerability was simple to exploit.

How is the vulnerability exploited?

Both CVE-2022-3602 and CVE-2022-3786 vulnerabilities are prone to buffer overflow attacks that can perform Remote Code Execution (RCE) or expose contents of the memory that contains private keys or proprietary information.

The chances of these vulnerabilities getting abused are low because one of the conditions is a malformed certificate signed by a trusted CA.

The issue lies in the verification process of certificates that OpenSSL performs for certificate-based authentication. The exploitation of the vulnerabilities could allow an attacker to launch a Denial of Service (DoS) or even an RCE attack.

Patches for the two weaknesses found in OpenSSL v3.0.0 to v3.06 have now been released.

Which OpenSSL versions are vulnerable?

• OpenSSL versions 3.0 and above are vulnerable.

• OpenSSL 3.0.0, the first stable version of OpenSSL 3.0, was released in September 2021, about one year ago. Any older operating systems prior to 3.0.0 are not impacted by this vulnerability.

• OpenSSL version 3.0.0 to 3.0.6 are affected by this vulnerability.

• OpenSSL version 3.0.7 includes the fix for the critical vulnerability.

CRITICAL Severity: This affects common configurations, which are also likely to be exploitable. Among these are significant disclosures of server memory (potentially revealing user information), vulnerabilities that are easily exploitable to compromise server private keys remotely, or situations where remote code execution is possible. We will keep these issues private and release a new version of all supported versions as soon as possible.

HIGH Severity: This includes issues that are of a lower risk than CRITICAL, perhaps due to affecting fewer common configurations or which are less likely to be exploitable. These issues will be kept private and will trigger a new release of all supported versions. We will attempt to keep the time these issues are private to a minimum; our aim would be no longer than a month, where this is something under our control.

What should security teams do?

Use ORDR’s vulnerability scanner or any other scanner with similar capabilities to identify if your organization uses the vulnerable OpenSSL version. If you are using OpenSSL 3.0, patch immediately.

Is the ORDR platform impacted by the OpenSSL vulnerability?

ORDR has reviewed our usage of OpenSSL. This vulnerability does not impact ORDR as we do not use the impacted version.

How ORDR helps

ORDR Scanner

ORDR uses an unauthenticated way to get information about OpenSSL versions while other scanners rely on an authenticated approach that requires full credentials. The ORDR scanner also uses tools like Nmap to find open ports as a precursor before determining the OpenSSL version. The ORDR Scanner uses the following:

• HTTPS headers, SSH headers, and credentialed scans to get the information.

• For assets that do have an open HTTP port, a cURL command can be used to determine the SSL version.

• For assets that do not have an open HTTP port, an SSH command can be used to determine the SSL version.

Sample ORDR Scanner SSL command

curl -s -I abcd.com
HTTP/1.1 301 Moved Permanently
Content-Type: text/html; charset=iso-8859-1
Content-Length: 229
Connection: keep-alive
Date: Fri, 04 Nov 2022 05:26:33 GMT
Server: Apache/2.4.6 (CentOS) PHP/5.4.16 OpenSSL/1.0.2k-fips
Location: https://www.abcd.com/
Via: 1.1 varnish (Varnish/6.0), 1.1 22dc875d744f932282ce89367c98a9de.cloudfront.net(CloudFront)
Vary: Accept-Encoding
X-Cache: Hit from cloudfront
X-Amz-Cf-Pop: SFO53-C1
X-Amz-Cf-Id: IQtd4xNPyLgvKHBfB39noPFh7hXdfTic_SYKQDWeCGQHNw2HdjIyLQ==
Age: 537

Sample ORDR Scanner SSH command

cpnadmin@ubuntu22-server:~$ ssh -v 10.30.11.184
OpenSSH_8.9p1 Ubuntu-3, OpenSSL 3.0.2 15 Mar 2022
debug1: Reading configuration data /etc/ssh/ssh_config

Detecting Exploit Attempts with a Signature Based IDS

Once the ORDR Scanner has detected all assets impacted by the vulnerability, the next step is to determine if the vulnerability is being exploited. ORDR has a signature-based intrusion detection engine that can scan for this and other exploits. ORDR has pushed the latest signature to all customers to identify and alert if malicious activity involving OpenSSL is detected.

Example signature to identify a potential exploit

alert tcp any any -> any any (msg:"SERVER-OTHER OpenSSL x509 crafted email address buffer overflow
attempt"; flow:established; content:"|06 03 55 1D 1E 01 01|"; content:"|04 82|"; within:2; distance:1;
content:"|30 82|"; within:2; distance:2; content:"|82|"; within:1; distance:3; content:"|30 82|";
within:2; distance:2; content:"|81 82|"; within:2; distance:2; byte_test:2,>,500,0,relative;
content:"xn--"; within:4; distance:2; fast_pattern; metadata:policy balanced-ips drop, policy
connectivity-ips drop, policy max-detect-ips drop, policy security-ips drop, ruleset community,
service ssl; reference:cve,2022-3602; classtype:attempted-user; sid:60790; rev:1;)

• CVE-2022-3602 - Detection of this pattern was done using IDS Signatures.

• A buffer overflow can be triggered by sending an X.509 certificate with a specially crafted email address in the “id-on-SmtpUTF8Mailbox” field (OID 1.3.6.1.5.5.7.8.9), resulting in a crash (Denial of Service - DoS) or potentially remote code execution on a vulnerable client or server. Potential opportunities for exploitation can occur if a server requests authentication information after a malicious client connects or if a client connects to a malicious server, which would then make the client vulnerable.

• “OpenSSL x509 crafted email address buffer overflow attempt” is detected with the following signature.

Frequently asked questions
Which OpenSSL v3 versions are affected by CVE-2022-3602 and CVE-2022-3786?
OpenSSL v3.0.0 through v3.0.6 contain critical remote code execution and denial-of-service vulnerabilities. ORDR's security bulletin identifies the specific affected versions and recommends immediate patching to v3.0.7 or later to close these attack vectors.
How do buffer overflow exploits work in OpenSSL v3?
The vulnerabilities exploit buffer overflow conditions in OpenSSL v3's X.509 certificate verification logic, allowing attackers to execute remote code or trigger denial-of-service conditions. ORDR details the specific attack mechanisms to help security teams understand exposure across their IoT and OT environments.
What's the fastest way to prioritize OpenSSL patching across my infrastructure?
ORDR recommends prioritizing patches based on asset criticality and external exposure first, then addressing internal-only systems. The security bulletin provides actionable guidance to systematically remediate vulnerabilities across your connected asset inventory without operational disruption.

This resource is published by ORDR, the connected asset security company. ORDR delivers AI-powered visibility, risk assessment, and automated protection for IoT, OT, and IoMT devices across healthcare, manufacturing, government, and financial environments. Browse all resources →

OpenSSL v3 Critical Vulnerabilities: CVE-2022-3602 & 37… | ORDR