This post was updated on November 2, 2022

‍

Today, OpenSSL released a security advisory for two vulnerabilities CVE-2022-3786 and CVE-2022-3602, that affect OpenSSL versions above 3.0.0 and below the patched version of 3.0.7, as well as applications with an affected OpenSSL library embedded.

‍

The OpenSSL cryptography library is a widely used implementation of the Transport Layer Security (TLS) protocol. In this blog post we will provide a brief technical analysis of the vulnerability, offer some guidance for teams mitigating this issue and provide context around what we can do as industry to prevent these types of vulnerabilities from happening.

‍

Technical Analysis

The OpenSSL vulnerabilities, CVE-2022-3602 and CVE-2022-3786, are related to how OpenSSL parses and validates the [emailAddress] certificate value, where a malformed certificate can crash the validation function through a specially crafted value by overflowing the punycode validator in the X.509 certificate parsing routines.

‍

For an application to be vulnerable, it must either be serving a malformed certificate as a TLS server, or request a malformed certificate which otherwise meets the application's validation policy. In practice, it is likely that vulnerability is not going to see widespread exploitation as some were originally concerned.

‍

Mitigation/Remediation Guidance

The first step to remediating this issue is determining whether you are vulnerable. If you are running OpenSSL versions above 3.0.0 and below 3.0.7 you most likely are. If the image comes with an SBOM, check there first. If not, you can try to generate an SBOM with a tool like Syft.

‍

You can check an image ad-hoc using the cosign CLI with a CUE policy:

$ curl -O -J \
https://gist.githubusercontent.com/johnfosborneiii/3d397043c87ed2c9f03d2f0af096e884/raw/16c4d8fc0c92c0564d4a79d295359f84f6d4a4d7/vuln-cve-2022-xxxx-openssl.cue

$ cosign verify-attestation \
	--policy=vuln-cve-2022-xxxx-openssl.cue \
	--type https://spdx.dev/Document \
	$IMAGE_URI

Unfortunately, some images – such as the official node image on Docker Hub – incorrectly report the version of OpenSSL that's used by the Node.js runtime. There may be other images that incorrectly report the version of OpenSSL being used, and report a prior non-vulnerable version instead of a more current vulnerable version. Some scanners may be able to detect the version of Node.js and implicitly know which version of OpenSSL is used there, but in our testing most scanners miss this. Unfortunately this means that SBOMs generated after the fact by Software Composition Analysis (SCA) tools and scanners can’t be trusted to contain enough information to help with effective patch management.

# Syft detects the image contains OpenSSL 1.1.1 (not vulnerable):
$ syft node | grep openssl
openssl                             1.1.1n-0+deb11u3                deb

# But the node runtime actually uses the vulnerable OpenSSL 3.0.5!
$ docker run node -e "console.log(process.versions)" | grep openssl
  openssl: '3.0.5+quic',

# The Chainguard Image for node correctly reports the version of OpenSSL it uses,
# due to its build-time SBOM.
$ cosign download sbom --platform=linux/amd64 cgr.dev/chainguard/node | grep libssl
libssl3-3.0.5-r3

# Syft doesn't have to detect what's in the image.
$ syft cgr.dev/chainguard/node | grep libssl
libssl3                             3.0.5-r3     apk

Once you've determined whether you're vulnerable, you can wait for a fix to be applied and released in the base image or package ecosystem you depend on, and rebuild to pick up that fix. We should expect fixes to be applied and made available quickly.

‍

Customer Guidance

Chainguard Images

Users of any Chainguard Image that depends on OpenSSL have one action to take: update to the latest image. Our team has released images with fixes for any one that contained the vulnerable version of OpenSSL.

‍

If you'd like to see whether the Chainguard Image you use has the vulnerability, you can consult its SBOM (using cosign download sbom <image>) or scan it with your favorite vulnerability scanner, to determine whether it contains a vulnerable version of OpenSSL. Chainguard Images' SBOMs are created at build time and are not susceptible to the issue that makes the official node image's OpenSSL version difficult to detect.

‍

This exemplifies our commitment to high-quality, trustworthy base images. We know this isn’t the last time we are going to face this issue, when the next vulnerability affects another common dependency you can trust Chainguard Images to clearly show when they're vulnerable, and when they're not, and to quickly apply any security fixes and make them available to you as soon as possible.

‍

Chainguard Enforce

Chainguard has published a sample policy for Enforce on our GitHub, which can be installed into a cluster to identify and optionally block workloads containing vulnerable versions of OpenSSL from running on customer clusters. To check a Kubernetes cluster or fleet of clusters using Chainguard Enforce, customers can do the following:

$ curl -O -J \
https://gist.githubusercontent.com/johnfosborneiii/3d397043c87ed2c9f03d2f0af096e884/raw/16c4d8fc0c92c0564d4a79d295359f84f6d4a4d7/vuln-cve-2022-xxxx-openssl.yaml

$ chainctl policies create --group $GROUP -f vuln-cve-2022-xxxx-openssl.yaml

Note: This policy is specific to images with a signed SPDX formatted SBOM and has been validated against libcrypto3 libssl3 packages 3.0.0.*-3.0.6.* but can be modified if your Linux distro has a different naming convention.

‍

Checking an image ad-hoc does not require any uninstall directions, but if you wish to remove the policy for Chainguard Enforce for Kubernetes you can either:

‍

• Switch the policy to warn only by setting spec.mode=”warn” in the policy file

• Remove the policy entirely by running

$ chainctl policy delete -y $(chainctl policy list -o json | jq -r '[.items[] | select(.name == "vuln-cve-2022-xxxx-openssl")][0].id')

Don’t wait, learn how Chainguard Enforce can help you mitigate your supply chain risk today.

Looking Ahead

These vulnerabilities will likely lead to many discussions around the perceived unsustainability and insecurity of open source, but the facts remain that major, well-funded vendors see bugs like this at a much higher rate. Instead of debating the merits of open source, we should instead focus on building secure software that has the tooling necessary to make remediation faster and more seamless by rooting it in secure by default measures. ‍SBOMs have not yet demonstrated the ability to help organizations with effective patch management for CVEs like this. A new approach is needed to make SBOMs effective, trustworthy and complete. To achieve this we need to generate SBOMs at build time, not after the fact. Bolted on, SCA-based supply chain solutions have missed the mark in scenarios like this. ‍The Linux Foundation created the Core Infrastructure Initiative (CII) in April 2014 in response to Heartbleed, largely an effort to raise funds from the world's largest tech companies to underwrite the OpenSSL developers and support other open source projects that we all depend on. ‍Despite this investment in resources, the fact remains that we are currently dealing with yet another vulnerability. Money is not going to solve this problem. The OpenSSF has worked hard to champion projects and organizations to support these types of efforts, but we need full scale adoption of practices like generating SBOMs at build time and mandatory code review if we are going to fix this problem.‍At Chainguard, we are committed to tackling software supply chain problems by providing developers and security leaders with the tools needed to build software securely proactively, not reactively. ‍Don’t hesitate to reach out if you need any help or guidance as your teams begin to address this issue.