Update: OpenSSL high severity vulnerabilities

OpenSSL has released two high severity vulnerabilities — CVE-2022-3602 and CVE-2022-3786 — related to buffer overrun. OpenSSL initially rated CVE-2022-3602 as critical, but upon further investigation, it was reduced to high severity.

What is Buffer overrun?

A buffer overrun/overflow is a specific type of runtime issue that allows a program to write past the end of a buffer or array and corrupt nearby memory — hence the name overflow. A buffer overflow does not appear during every program execution, like most issues do. Instead, specific conditions, such as unexpected user input, are required to activate the vulnerability.

Both of the high severity vulnerabilities are exploited by name constraint checking during X.509 certificate verification.

X.509 Email Address 4-byte Buffer Overflow (CVE-2022-3602)
X.509 Email Address Variable Length Buffer Overflow (CVE-2022-3786)

The vulnerability can be triggered in a TLS client by connecting to a rogue server. It could also be triggered on a TLS server if a malicious client joins when the server requests client authentication.

OpenSSL version 3.0.7 was released as an open source toolkit for SSL/TLS. Any OpenSSL 3.0 program should be regarded as insecure and exploitable by attackers if it checks X.509 certificates obtained from unreliable sources.

TLS client authentication should be disabled on clients and servers until the upgrade has been applied.

Affected Versions

OpenSSL versions 3.0.0 to 3.0.6 are vulnerable to this issue.

Unaffected versions

1.1.1
1.1.0
1.0.2
1.0.1
1.0.0
0.9.x
fips

Impact

Denial of Service
Remote Code Execution

How can Snyk Help?

Snyk Open Source

Now that the vulnerability details have been made available, Snyk Open Source projects will flag the vulnerability in their next retest. For projects configured for daily testing, that will happen within the next 24 hours. Clients can, of course, manually trigger retests on critical projects to see these results sooner.

You can also scan open source codewithin the Snyk CLI using the snyk test command.

Snyk Container

When an advisory like the OpenSSL CVE is issued, each Linux distro maintainer then has to triage and issue their own advisory. It’s this distro advisory that triggers the detections in Snyk Container. This means there will likely be some lag between the OpenSSL advisory and the first Snyk Container detections, based on how quickly the Linux distro maintainers release their advisories. Learn more about how this process works with our post on simplifying container security.

Once that happens, you’ll see these detections flagged in Snyk Container test results. For both Snyk Open Source and Snyk Container, you’ll see results in reporting up to 9 hours after the above conditions are met due to existing data latency. This latency may be shorter when using the beta reporting to view issues.

Recommendations

OpenSSL 3.0 users should upgrade to OpenSSL 3.0.7.
Stack overflow protections

Update on the data for Ubuntu advisories in Snyk VulnDB

References

Protect your applications for free

Create a Snyk account today to find and fix vulnerabilities in your code, dependencies, containers, and cloud infrastructure.