This blog will be updated as new information becomes available

Based on our current understanding of the vulnerabilities, CVE-2022-3786 and CVE-2022-3602, patched in OpenSSL 3.0.7, GreyNoise is unlikely to observe opportunistic mass exploitation in the wild.

What is being patched?

On Oct 25, 2022 the OpenSSL project authors announced via mailing list that OpenSSL 3.0.7 would become available on Nov 1st, 2022 between 1300-1700 UTC and include a high severity, marked HIGH, security-fix

The release occurred on Nov 1st, 2022, at 1600 ET and includes fixes for affected versions v3.0.x through v3.0.6. The patch, available here, addresses following issues:

Added RIPEMD160 to the default provider.
Fixed regressions introduced in 3.0.6 version.
Fixed two buffer overflows in punycode decoding functions. CVE-2022-3786 and CVE-2022-3602.

OpenSSL is a library that provides general purpose cryptographic functions. As with any usage of cryptographic operations, there is a reasonable expectation that operation involves sensitive data and any disclosure of information is highly problematic in nature.

The full change log provides the full description of both vulnerabilities as follows:

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])

‍

For additional details, see OpenSSL Security Advisory [01 November 2022].

Am I impacted?

OpenSSL is a library and toolkit that can be used in a variety of ways. The most common integration scopes are via the System, or as a Dynamically or Statically linked library. The security vulnerabilities addressed in today’s patch address versions v3.0.x through v3.0.6. If you are not utilizing a version within that range then you are not affected by these vulnerabilities.

System

If OpenSSL is installed as a toolkit on your system you can quickly check by running the command openssl version which will report back the installed system version.

Dynamically or Statically Linked

When OpenSSL is utilized as a library in a larger program it can be linked Statically or Dynamically.

When OpenSSL is statically linked, the library is bundled into the resulting executable of program when it is compiled, making the single executable contain all of the needed functionality as a single file.

When OpenSSL is dynamically linked, the library is expected to already exist on the system for which the program is expected to run. When the program is executed it searches a list of filesystem paths to locate the OpenSSL library and loads it as needed.

If you have access to the source code for the program you wish to evaluate for this vulnerability, the best way way is check for usage of the openssl3 library in the dependencies.

If you do not have access to source code, we recommend reaching out to the software vendor to ask for an evaluation and corresponding announcement. There are operating system specific methods to attempt to evaluate this yourself, but they require a more complex understanding of how libraries are loaded when a program is run. We recommend reaching out to the software vendor and requesting an announcement if you believe the software may be impacted. The software vendor should be able to answer in confidence.

What does this look like in the real world?

OpenSSL 3.0.0 was released in September 2021 meaning that its usage is not as pervasive in older, more widely deployed software. For more details, see Censys’ blog regarding potentially vulnerable OpenSSL 3.x enabled devices.

In a self-evaluation of all of GreyNoise’s infrastructure which included our wide array of honeypot style sensors spread across a large variety of operating systems and cloud providers we did not identify any usage of vulnerable versions of OpenSSL v3.0.x

This will not hold true of all organizations, but it is a data-point we can provide at this time.

What are next steps?

Evaluate your environment for usage of OpenSSL <v3.0.7
Update dependencies to utilize OpenSSL v3.0.7+
Contact software vendor for support if you believe a vulnerable version of OpenSSL is statically linked to software your organization runs.