Lessons from OpenSSL vulnerabilities part 1: Preparing your supply chain for the next critical vulnerability

It's early in the morning on an unseasonably warm Tuesday in October. You're checking your email as you enjoy your first cup of coffee or tea for the day, and you almost do a spit-take when you read that OpenSSL has a forthcoming release to fix a CRITICAL vulnerability. Immediately, visions of Heartbleed pop into your head. You quickly draft a Slack message to your boss, and realize — just before you click "send" — that you know exactly what they're going to ask: where are we impacted, and how are we going to fix it?

The OpenSSL project team gave about one week's panic notice for the vulnerability. When they finally published what was fixed by version 3.0.7, they ended up downgrading the severity level to high and shared two new vulns. But what if this was the next Heartbleed? Would you be ready? How would you find out if — and where — you're impacted? Where would you even need to look? After all, it's not "if" there will be a new critical vuln in a commonly used library, it’s "when." 

In this two part series, we'll walk through some of the things you need to consider when finding instances of a vulnerability in your software supply chain. While this series will focus on OpenSSL and relevant libraries, we'll also consider vulnerabilities across the board. Let’s begin by discussing where you’ll need to look for vulnerable libraries, and review some tips and tricks for searching.

Where to look for vulnerable libraries in your supply chain

The two new OpenSSL CVEs (CVE-2022-3602 and CVE-2022-3786) are both buffer overflow issues that impact OpenSSL versions 3.0.0 through 3.0.6. Luckily, 1.x versions, which are far more prevalent in the wild, were not impacted. "Great," you might think, "all that I have to do is look for any of my hosts that have OpenSSLv3 installed." While that's a step in the right direction, there are more things to consider, and many more places (and ways) vulnerable versions might be lurking.

Hosts, VMs, and container images

The resources you use to run workloads aren’t commonly considered part of the supply chain, but don't overlook them. In addition to checking physical hosts for impacted versions of OpenSSL — servers, desktops, laptops, and workstations — you also need to take virtual hosts into consideration. These might be virtual machines (VMs) that you have running under your own hypervisors, but they can also be compute instances on AWS, GCP, Azure, or any other cloud providers. These cloud instances, whether they're EC2, GCE, or some other branded acronym, are all potential points of exploitation. Good cloud and network configurations can limit access to these instances, but it's better to maintain a queryable inventory. You can do this by installing endpoint protection on your hosts, or via native cloud tools like AWS Inspector (which discovers AWS workloads in the AWS environment across EC2). In this blog, we'll focus on the software side of things.

In addition to having physical and virtual hosts, more than 90% of the organizations we surveyed also run dynamic and ephemeral containerized and serverless workloads, which can be a little more tricky to scan. These workloads are ephemeral in that they can be short-lived, and they're dynamic in the respect that they might get instantiated on a schedule or by triggering events. With this in mind, you can't just look at the containers that are running, you also need to check the container images in your inventory, which could amount to hundreds or thousands of images. 

Container images are typically stored in a container registry, such as Docker Hub, Quay, or JFrog Artifactory, or in an image repository provided by the cloud vendor. Additionally, images might be deployed as workloads or used as the foundation  — or base image — for other images. Vulnerabilities are often transitive. If you identify an instance of a vulnerable package in a container image, it's possible, and even likely, that any derived images that come `FROM` that image are impacted as well.

This should give you a good idea of places to look for OpenSSL from a "hosts" (physical, virtual, and ephemeral) perspective. These are the places that OpenSSL was likely installed via package managers — for example `brew (or yum, or apt) install openssl`, or from downloaded and manually installed packages. There are, however, other ways vulnerable packages can make it onto your systems.

Source code and dependencies

You might have specific versions of OpenSSL installed on your hosts — for example when you install a version to allow you to SSH to or from other hosts. Whether these top-level occurrences are vulnerable or not, there could be additional instances that get installed by or alongside the software you use, or by the software that you develop and deploy. These instances infiltrate your supply chain when your code has a direct dependency on OpenSSL libraries. For example, if your application specifies OpenSSL libraries in its dependencies, like `requirements.txt`, `pom.xml`, or `Gemfile`. It can also occur if something in your application​​'s dependency tree requires OpenSSL, even when the transitive dependencies are many layers deep. For example, your app leverages a helper library, which, in turn, relies on a crypto library, cascading until the dependency tree shows that library "qux" pulled in OpenSSL 3.05, while none of the intermediate libraries even appear in your three-line `Gemfile`. If something in your application dependency tree pulls in OpenSSL libraries, then your application's software bill of materials (SBOM) will include the OpenSSL libraries as well.

Occasionally, application developers simply copy in and distribute OpenSSL libraries with their applications, rather than including them via package managers. In this case, an application essentially embeds the library during the build process, rather than relying on the presence of external libraries.

Prepare for the next supply chain vulnerability with Snyk

When you leverage Snyk Container and Snyk Open Source to secure your software supply chain, you can proactively monitor your containers and open source projects. Rather than having to scramble to find occurrences of vulnerable container images or open source packages you can know if you're impacted before the vulnerabilities are even published, so you can feel confident that you have the answers when you click the "send airplane" in Slack, firing off that message to your boss.

If you don’t have one already, create a free Snyk account today to save time and energy in your search process. And come back next week for our continued discussion on how to find — and fix — supply chain vulnerabilities.