New OpenSSL critical vulnerability: What you need to know

On Oct 25, 2022, the OpenSSL project announced a forthcoming release of OpenSSL (version 3.0.7) to address a critical security vulnerability. The vulnerabilities (there were two, instead of one) went live on Tuesday, November 1, 2022 and the OpenSSL project published a blog detailing the issues and fixes. A separate blog from Snyk also delves into the vulnerabilities and why they were downgraded from Critical to High. This blog focuses on how to use Snyk to prepare for vulnerabilities like this one, and has been updated based on the latest information.

Snyk has published an advisory with the current known details and will update this advisory if any new details are publicized.

About the vulnerability

The OpenSSL project has marked this vulnerability as critical, but said it will not impact versions of OpenSSL prior to 3.0. This means that if you’re using a version of OpenSSL lower than 3.0, you should be unaffected for now.

The OpenSSL project’s security policy outlines what they consider critical vulnerabilities:

This affects common configurations and which are also likely to be exploitable. Examples include significant disclosure of the contents of server memory (potentially revealing user details), vulnerabilities which can be easily exploited remotely to compromise server private keys or where remote code execution is considered likely in common situations. These issues will be kept private and will trigger a new release of all supported versions. We will attempt to address these as soon as possible.

You can read more about why they decided to downgrade the severity to critical in the OpenSSL blog.

The vulnerable versions of OpenSSL (3.0 and above) are currently used in Linux operating systems including Ubuntu 22.04 LTS, RHEL 9, and others. However, Linux distros like Debian only include OpenSSL 3.x in their most recent releases, which are still considered testing versions, and thus widespread use in production systems may be limited. Container images built using affected versions of Linux will also be impacted. However, it is worth noting that many popular Docker Official images use Debian Bullseye (11) and Alpine, which still use OpenSSL 1.x and are not impacted. The Docker Official container images for projects like nginx and httpd, popular for handling web traffic, also use Bullseye and Alpine and are unaffected.

Node.js 18.x and 19.x also use OpenSSL3 by default, so we anticipate upgrades coming for Node.js in the next few days.

Finally, if your own developers use C/C++, they may be incorporating OpenSSL v3 packages in their code. You should check this code for the relevant OpenSSL packages.

How to know if you’re impacted before vulnerabilities are published

One of the interesting things about this vulnerability is that the OpenSSL project announced that an important security fix was on the way a week ahead of its release. Because it was noted that there was at least one critical vulnerability, folks had time to figure out how to search for potentially affected applications, containers, and servers. After vulnerabilities are published, security tools like Snyk will obviously detect their presence and provide fixes. But before the vulnerability is published, how can we use Snyk to come up with a game plan?

The steps that follow are for this OpenSSL vulnerability. But these steps could be used for any vulnerability about which details are known ahead of time, as long as you have a software bill of materials and you’re doing full SCA analysis for all of your open source code packages and containers.

If you’re a Snyk customer on a Business or Enterprise plan, you can find all projects that include vulnerable versions of OpenSSL (3.0.x). Go to Reports, then Dependencies. In the search box, enter openssl to see where you may be using 3.0.x versions. The Projects link takes you to relevant projects. If you prefer, you can export the data to a CSV file.

Customers with access to the Snyk APIs (Business and Enterprise plans) can also use the API to extract this data. For example, you can use a utility provided by the Snyk Labs team, called snyk-deps-to-csv, to extract dependencies to a CSV. You can also access the dependencies API yourself.

Any Snyk user, including users of free accounts, can scan for a vulnerable version of OpenSSL by going to the Snyk dashboard, selecting a project, then clicking the Dependencies tab and searching for “openssl”. Again, OpenSSL 3.0.x versions are the ones that will be affected.

If you haven’t yet tested your projects with Snyk, you can do so with our Snyk CLI:

• To test your code projects for open source packages like OpenSSL, or transitive dependencies that use OpenSSL, run snyk test to see results directly in your CLI or snyk monitor to see results in the Snyk web UI.

  • If you’re using C/C++ and want to know if you have OpenSSL included in your project outside a package manager (unmanaged), add the --unmanaged option when running snyk test.

• To test container images, run snyk container test to see results directly in your CLI or snyk container monitor to send the results to the Snyk web UI.

• For either type of test shown above, to view the dependency list in your CLI add the --print-deps option. If you’re using the monitor command, the dependencies are automatically reported in the Snyk web UI.

• If you’re a Linux user, you can verify what version of OpenSSL you’re using by simply running the openssl version command in your terminal:

How to mitigate the new OpenSSL vulnerability

1. Let team members know about the vulnerability announcement and upcoming security release next Tuesday, November 1, 2022. Making sure your team is aware of the issue and the upcoming release is the best way to prepare.

2. Assess your applications and infrastructure to determine whether or not you’re using OpenSSL 3.0 or above anywhere.

3. Prepare to update any vulnerable OpenSSL installations on Tuesday, November 1, 2022.

If you’re using Snyk to help detect and fix vulnerabilities, we’ll have the vulnerability addressed in our database and will detect it as you scan projects on November 1 2022 when details are made public. You will be prompted to update any vulnerable versions tracked by Snyk when fixes are available.

Don’t panic!

Managing critical vulnerabilities can be stressful, but don’t panic! The OpenSSL project has a long track record of responsibly handling security incidents and providing timely fixes.

If you aren’t already using a vulnerability detection tool like Snyk, now might be a good time to try one out — they’ll help notify you of incidents like this when they arise, and potentially even help you roll out security fixes when available.

While it’s impossible to fix every issue, staying on top of the critical ones and updating quickly is a solid strategy for reducing risk and avoiding breaches.

More information

These additional resources related to the upcoming vulnerability may be useful as you prepare:

• Snyk Advisory

• Docker DSA 2022-0001: a temporary advisory in anticipation of the public CVE but provides a list of affected packages and public container images.

• SANS Internet Storm Center: a List of affected Linux distributions

• DistroWatch: a List of affected Linux distributions

• Node.js notice: the security release from Node.js, highlighting that Node.js v18.x and v19.x use OpenSSL v3