Change Log: 

• 2022-10-25: The vendor released a statement that a critical vulnerability will be announced on 2022-11-01.
• 2022-11-01: OpenSSL Project released a security bulletin assigning these issues CVE-2022-3602 and CVE-2022-3786.
• 2022-11-01: OpenSSL Project releases a blog post describing the vulnerabilities.
• 2022-11-01: This report published.

What Do We Know About The OpenSSL Vulnerabilities? 

Pre-announcements of CVE-2022-3602 and CVE-2022-3786 described these issues as CRITICAL. Further analysis based on some of the mitigating factors identified have led these issues to be downgraded to HIGH. Users are still encouraged to upgrade to a new version as soon as possible.

While there was originally a single vulnerability mentioned by the OpenSSL team, the recent announcement discloses that there are two unique issues: CVE-2022-3786 and CVE-2022-3602. 

On November 1, 2022 the OpenSSL Project provided an update that patched CVE-2022-3602 and CVE-2022-3786. These vulnerabilities are stack-based buffer overflows in X.509 certificate parsing that affect both client and server code. OpenSSL 3.x prior to 3.0.7 is susceptible and Randori has found numerous matching versions exposed on internet-facing assets.

Key Takeaways 

• The vulnerabilities are not likely to be exploited in a real-world scenario.
• An updated version of OpenSSL (3.0.7) has been released to address the vulnerabilities and affected systems should be updated.
• Proof of concept code has been published.
• There have been no reports of exploitation.
• OpenSSL is embedded within many applications and systems which makes identifying vulnerable products difficult.
• The following mitigating circumstances can affect exploitability:
  • The vulnerability affects the 3.x branch of OpenSSL, which is not as ubiquitous as the 1.x versions.
  • The issues are stack-based buffer overflows and are non-trivial to reliably exploit.
  • In most default configurations, exploitation requires valid certificates and cannot be triggered with a self-signed certificate or an invalid certificate chain. 

The Randori Attack Team has successfully triggered the vulnerabilities in a lab environment. Review the Randori Technical Analysis Section for an overview of the vulnerabilities and details on exploitation.

What Is The Scope Of The OpenSSL 3.X Vulnerability Announcement?

OpenSSL is a ubiquitous library that is almost assuredly present in most environments. The announced CVE-2022-3602 & CVE-2022-3786 impact OpenSSL versions 3.0.0 – 3.0.6. 

OpenSSL 3.x branch has only been around since 2021-09-07. Based on this survey it is estimated that less than 0.2% of internet facing sites leverage OpenSSL v3.0 or higher, where roughly 75% of sites leverage the more popular version of OpenSSL v1. 

How Could An Adversary Uncover What Version of OpenSSL My Organization is Leveraging?

Adding complexity to the pending OpenSSL vulnerability announcement, systems utilizing OpenSSL do not generally advertise version information. OpenSSL is most commonly used as an encryption layer around other protocols. 

In rare cases, the software using OpenSSL may expose what version it was compiled against. For example, Apache configured with a default “ServerTokenDirective” will respond to HTTP requests with the OpenSSL version in the Server header.

This OpenSSL version abstraction acts as a double edge sword, while it will increase complexity for practitioners without a detailed SBOM to uncover OpenSSL versions, this complexity will lend in favor of adversaries. As there is likely no ill effect of attempting exploitation against invulnerable targets, expect adversaries to make attempts indiscriminately across a wide breadth of systems.

Note: There is no known working exploit at this time which could lead to code execution, and no evidence of current exploitation.

Randori Technical Analysis of CVE-2022-3602 & CVE-2022-3786

The Randori Attack team performed testing in a lab environment on systems with the following configuration: OpenSSL 3.0.5 on Alpine Linux

CVE-2022-3602 and CVE-2022-3786 are buffer overflows in the parsing of punycode data within certificate e-mail addresses by OpenSSL 3. CVE-2022-3602 allows for the writing of 4 bytes of controlled data beyond the bounds of a fixed-length buffer and CVE-2022-3786 allows for control over the amount of writes but not the contents.

Exploitation

There are two scenarios in which these vulnerabilities may be triggered:

• A vulnerable client may be exploited when connecting to a malicious server.
• A vulnerable server may be exploited if a malicious client responds to a client authentication request.

Exploitation for anything beyond denial of service in real-world scenarios is unlikely, for the following mitigating reasons:

• For CVE-2022-3786:
  • the data that is overflowing is not controlled by the attacker.
• For CVE-2022-3602:
  • The amount of the overflow is limited to 4 bytes.
  • The data that can be overwritten is not useful for gaining code execution.
• For both:
  • Modern applications, which are the ones most likely to use OpenSSL 3, make use of compiler features such as address space layout randomization. This makes exploitation much less reliable.
  • Most targets will require a signed certificate or valid certificate chain and thus not be exploitable.

Testing for Vulnerability

Systems with the vulnerable OpenSSL library can be identified through both local and remote methods. 

Local Detection

On Linux and Unix systems, the presence of libssl.so.3 indicates the vulnerable library might be exposed. To detect the library currently in use, the lsof command can be used as follows:

This will show any processes that currently have the library loaded into memory and thus potentially exposed.

Additionally, there are many other methods for various systems documented by NCSC-NL here: https://github.com/NCSC-NL/OpenSSL-2022/tree/main/scanning.

Remote Detection

There are numerous ways to detect remote instances of OpenSSL 3. In the most forthcoming scenario some HTTP servers will respond with their OpenSSL version in a Server header:

However, in most cases detecting the presence of OpenSSL 3 is more complicated and requires differential analysis at the protocol layer to identify deltas in behavior between various versions.

How Does Randori Expect the OpenSSL Vulnerability To Evolve Going Forward?

Due to the multitude of mitigating factors, it is not believed that these vulnerabilities will be exploited in real-world scenarios. Randori expects that adversaries will increase their capabilities with regard to identifying versions of OpenSSL, but that actual exploitation for remote code execution is unlikely. 

Mitigating CVE-2022-3602 & CVE-2022-3786 Vulnerabilities 

Recommended course of action is to identify any usage of OpenSSL version 3.x in your environment. If there is any usage of openssl-3.0.x plan to upgrade to version 3.0.7, test and publish updates on an accelerated timeline for all externally facing systems.

However, based on the complexity behind uncovering the OpenSSL version number it is imperative that organizations continue to monitor and investigate any known application or OS which ships with OpenSSL 3 by default as this will be a likely avenue for adversaries to target successfully. 

For ongoing investigations on impacted applications refer to OpenSSL Vulnerable Software Repo.

References

• Pre-announcement of vulnerability: https://mta.openssl.org/pipermail/openssl-announce/2022-October/000238.html 
• Vendor advisory: https://www.openssl.org/news/secadv/20221101.txt 
• Vendor blog post: https://www.openssl.org/blog/blog/2022/11/01/email-address-overflows/ 
• Github proof of concept: https://github.com/colmmacc/CVE-2022-3602 
• NCSC-NL repository: https://github.com/NCSC-NL/OpenSSL-2022/