Threat Signal Report

OpenSSL Release (3.0.7)

description-logo Description

Today, the OpenSSL Project released a new version of OpenSSL (v3.0.7). Last week's early announcement indicated at first this was a CRITICAL vulnerability and included a fix for it. There was various chatter that this recent disclosure could be potentially similar to HEARTBLEED , but after today's announcement the issue was downgraded from CRITICAL to HIGH.


Two vulnerabilities were disclosed, both are X.509 Email Address Buffer Overflows, and are vulnerable to denial of service attacks and the other, remote code execution.


Why is this Significant?

This is significant because the critical vulnerability exists in OpenSSL which is a widely adopted cryptographical toolkit used to achieve secure communications over the internet. Past critical vulnerabilities in OpenSSL resulted in remote code execution and information leaks, where the highest profile disclosure was HeartBleed back in 2014.


What are the Details of the Critical Vulnerability in OpenSSL?

Disclosed today by OpenSSL are two vulnerabilities:


CVE-2022-3602 - X.509 Email Address 4-byte Buffer Overflow

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. 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.


CVE-2022-3786 - X.509 Email Address Variable Length Buffer Overflow

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 a malicious certificate or for an application to continue certificate verification despite failure to construct a path to a trusted issuer. An attacker can craft a malicious email address in a certificate 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).


Are there Reports of Exploitation in the Wild?

According to OpenSSL, no.


What is the CVE Assignment for the Vulnerability?

CVE-2022-3602 and CVE-2022-3786 have been assigned to these vulnerabilities.


What is the CVSS score?

According to OpenSSL, they do not provide CVSS scores.


What is the Status of Protection?

FortiGuard Labs released the following IPS signature for CVE-2022-3602:

  • OpenSSL.X509.Punycode.Buffer.Overflow (default action is set to "pass")


For further information on products affected by this latest disclosure, please reference the OpenSSL3 critical vulnerability from Fortinet PSIRT in the Appendix section.


Any Recommended Mitigation?

OpenSSL suggests users operating TLS servers may consider disabling TLS client authentication, if it is being used, until fixes are applied. FortiGuard Labs highly recommends organizations utilizing OpenSSL update OpenSSL to version 3.0.7.

Telemetry


Definitions

Traffic Light Protocol

Color When Should it Be used? How may it be shared?

TLP: RED

Not for disclosure, restricted to participants only.
Sources may use TLP:RED when information cannot be effectively acted upon by additional parties, and could lead to impacts on a party's privacy, reputation, or operations if misused. Recipients may not share TLP:RED information with any parties outside of the specific exchange, meeting, or conversation in which it was originally disclosed. In the context of a meeting, for example, TLP:RED information is limited to those present at the meeting. In most circumstances, TLP:RED should be exchanged verbally or in person.

TLP: AMBER

Limited disclosure, restricted to participants’ organizations.
Sources may use TLP:AMBER when information requires support to be effectively acted upon, yet carries risks to privacy, reputation, or operations if shared outside of the organizations involved. Recipients may only share TLP:AMBER information with members of their own organization, and with clients or customers who need to know the information to protect themselves or prevent further harm. Sources are at liberty to specify additional intended limits of the sharing: these must be adhered to.

TLP: GREEN

Limited disclosure, restricted to the community.
Sources may use TLP:GREEN when information is useful for the awareness of all participating organizations as well as with peers within the broader community or sector. Recipients may share TLP:GREEN information with peers and partner organizations within their sector or community, but not via publicly accessible channels. Information in this category can be circulated widely within a particular community. TLP:GREEN information may not be released outside of the community.

TLP: WHITE

Disclosure is not limited.
Sources may use TLP:WHITE when information carries minimal or no foreseeable risk of misuse, in accordance with applicable rules and procedures for public release. Subject to standard copyright rules, TLP:WHITE information may be distributed without restriction.