New OpenSSL critical vulnerability: What you need to know

SnykSec - Nov 14 '22 - - Dev Community

On Oct 25, 2022 The OpenSSL project announced a forthcoming release of OpenSSL (version 3.0.7) to address a critical security vulnerability. This release should go live on Tuesday, November 1, 2022 between 1300 and 1700 UTC. Snyk has published a placeholder advisory with the current known details, and will update the advisory when official vulnerability details are publicized.

The last critical vulnerability in OpenSSL was released in 2016. Our security team will add this latest vulnerability to the Snyk vulnerability database as soon as more details are available.

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.

In short: if you’re using OpenSSL 3.0 or above, be ready to immediately upgrade to the upcoming 3.0.7 release on Tuesday, November 1st, 2022 in order to prevent a potential breach.

The vulnerable versions of OpenSSL (3.0 and above) are currently used in Linux operating systems including Ubuntu 22.04 LTS, MacOS Ventura, Fedora 36, 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

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 ourSnyk 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.
    • Docker Desktop users can also run docker scan to test container images. Use the --dependency-tree switch to see a concise output of the packages in a container.
  • 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:

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .