OpenSSL: Another Supply Chain Vulnerability
By now, you’ve likely already heard that there is a new set of vulnerabilities in OpenSSL, a popular open-source library included in most Linux distributions and many other software packages (including firmware). The flaw exists in OpenSSL version 3.0.0 through 3.0.6 and is fixed in OpenSSL version 3.0.7 (released on November 1, 2022). The threat to the software supply chain in this case can manifest itself in a number of ways, including:
- The environment (operating system or container) that your application is running on contains a vulnerable version of OpenSSL.
- A 3rd party application (software that you are not developing) includes a vulnerable version of OpenSSL.
- Appliances (Firewalls, VPN) and/or firmware on your devices have included a vulnerable version of OpenSSL.
The challenge with software supply chain threats is discovering these vulnerabilities in your organization as they can be tucked away in everything from a transient dependency to embedded inside the firmware.
Determining Priority
On November 1, 2022, the OpenSSL project released the details, which include two CVEs: CVE-2022-3602 and CVE-2022-3786. Both reference a flaw triggered in X.509 certificate verification. The pre-announcement deemed one of the vulnerabilities “Critical”. Once the official announcement was made, due to the difficulty of exploitation after further research (and stack overflow protection mitigations), the vulnerability was downgraded to “High”. The Datadog Security labs team published an extensive write-up, including all of the vulnerability details with code snippets and example code that will cause OpenSSL to crash. Exploitation of one of the vulnerabilities is still considered possible, though difficult to achieve given the most recent research.
Before we declare “the sky is falling”, I’d like to be quick to point out that OpenSSL 3.x is not as widespread as OpenSSL 1.1.x (which does not, to our knowledge, contain critical level vulnerabilities known at this time). The SANS Internet Storm Center wrote an article titled “Upcoming Critical OpenSSL Vulnerability: What will be Affected?”, listing several Linux distributions and which OpenSSL versions they are running. 1.1.x is the predominant version for many of the most popular Linux distributions. A quick check of my Linux systems running Manjaro Linux, an Arch Linux-based distribution, reports OpenSSL version 1.1.1q (You can find an even more comprehensive list of (un)affected software from NCSC). Our very own Nate Warfield showed an example Shodan query that uncovers the OpenSSL version via HTTP headers (which is only valid if the server is configured to leak such information) and found over 54,000 servers exposed to the Internet. A dataset from Wiz (based on analysis from hundreds of cloud environments) shows just over 65% of installations are based on version 1.1.1, with only 1.5% based on 3.0.x. This data makes sense given that OpenSSL 3.0.x was released just over one year ago.
Don’t Get Caught Up In The Hype
Of course, the above data is collected from sources “above the surface”. I believe we will find a few more instances below the surface as we start to hunt for OpenSSL in non-Internet exposed devices, enterprise appliances, and, of course, firmware. Vulnerabilities that are more critical than either of the recent OpenSSL ones are included in firmware, appliances, and software alike. They can remain hidden from vulnerability management and composition analysis software targeted at developers because they lie in third-party software binaries. While solutions exist to look into third-party binaries, the focus remains on looking at source code dependencies. While this is important, it’s an upstream supply chain solution, as you have to rely on the upstream provider to detect vulnerable libraries in their codebase (and know if the software uses an included library or one from the operating system, which may not always happen).
Firmware is perhaps one of the stealthiest places to hide as it is not easily accessible. Routers, switches, firewalls, BMCs, and VPN appliances may also have issues similar to OpenSSL. Even more concerning are the flaws that are remotely accessible and even more easily exploitable than the recent OpenSSL vulnerabilities. In the past two weeks, we’ve seen disclosures of high-severity vulnerabilities from Juniper, F5, and Fortinet. These enterprise appliances typically govern network communications and aim to add a level of protection that prevents attackers from moving deeper into your network. The recent vulnerabilities are also far easier to exploit, primarily because they target the web management interfaces of your devices, not with memory corruption, but authentication bypass.
Don’t lose focus on what are likely more important issues to address. Evaluating vulnerabilities and prioritizing remediation remain one of the most difficult tasks for defenders. Getting caught up in the vulnerability hype cycle can disrupt your processes and leave you more vulnerable than before.
