OpenSSL Critical Security Issue

The OpenSSL project has announced that a critical severity vulnerability exists in versions 3.0.x of the project. The fix will be released in version 3.0.7, expected November 1, 2022.

The OpenSSL project maintainers have not disclosed the specifics about the vulnerability for now. However, what we do know so far is that versions 1.x of the OpenSSL project ARE NOT affected.

What you need to do

It boils down to two things:

1. Determine if you are using the vulnerable package
2. Upgrade with the fixed package if so

Determine if you are using the vulnerable package

If you happen to have an SBOM in place, then this should be pretty quick. For example, if you are using the boostsecurityio platform, then just perform a quick:

What you are looking for is versions 3.0.x of the openssl package.

However, one thing to note is that SBOM’s can be generated using a multitude of configurations, and at different stages of the build process. For example, some tools will scan your dependency manifest files (package.json, requirements.txt, etc.) prior to the container build process. In such cases, you will see references to the binding for openssl, but not necessarily the actual c library itself.

In the screenshot above for example, you may see pyopenssl v22.0, but see no direct openssl library. This does not mean that you do not have openssl, just that at the time of scan, what was scanned did not contain the shared library that is part of the base layer OS packages.

For this reason, you want to ensure that you have the SBOM generated after the container build process.

If you do not have a post-container-build SBOM scan step — then you can use on of many open source image scanners, and grep for the outdated package.

For your vendors, you could ask for the SBOM as well and inspect it to determine if they themselves are affected by it.

Upgrade with the fixed package

If you are affected by the package, then be ready to upgrade. The specifics will depend on what base image you are using. For example:

• If you are using ubuntu:latest, it will receive the updated package automatically. You only need to ensure that you re-build the image and redeploy.
• If you are using a pinned version, you will need to ensure that the upstream software repository is still receiving critical security fixes such as this one, and that you update the package list, and upgrade. On ubuntu/debian systems this would be using apt-get update && apt-get upgrade -y at the appropriate location in your Dockerfile.

In conclusion

This will not be the last time issues of this nature happen, and as such, it is important to recognize the benefit that having up-to-date SBOM machinery in place provides. Gaining visibility across a multitude of repositories, code bases, images, and where they end up in production is step 1 in dealing with critical severity issues of this nature.