.webp)
The technology industry is in the midst of active discussions about the use of “software bill of materials” (SBOMs) to address supply chain security risks. In order to implement supply chain security practices, there must be better transparency on software dependencies. Previously, any piece of software shipped as black-box without providing any information related to software dependencies and third-party components. Firmware has largely been looked at the same way. In an earlier blog post, Binarly team discussed the multiple levels of complexity in the UEFI firmware ecosystem and supply chain taxonomy (The Firmware Supply-Chain Security Is Broken: Can We Fix It?).
Can SBOMs help to increase transparency for proprietary firmware packages? The answer is complicated. SBOMs can help to better understand the dependencies but, in many cases, the vendors are distributing SBOM information separately from firmware packages or images. That creates the same problems as previous discussions around supply chain issues when SBOM is not relevant or can contain misleading information. Now we have a supply chain tied to SBOM and in many cases, the SBOM is a static snapshot of the information provided by the vendor.
When the firmware does not include corresponding source code, it is difficult to validate SBOM information based on compiled binary modules without comprehensive code analysis infrastructure.
Earlier this month, CISA published a security advisory related to OpenSSL's recent high-severity security issues (CVE-2022-3602 and CVE-2022-3786). Both CVE-2022-3602 and CVE-2022-3786 security vulnerabilities are related to an x.509 certificate verification failure that can lead to a stack-based buffer overflow. In fact, the older versions are not affected such as OpenSSL 1.0.2 and 1.1.1. Earlier versions are also unaffected as the vulnerable code was introduced for the first time in OpenSSL 3.0.0.
The Binarly REsearch team decided to take a deeper look into how such urgent updates are reflected on the UEFI firmware supply chain ecosystem, and how diversified the widespread use of OpenSSL versions are in the firmware context.
One of the core frameworks EDKII used as a part of any UEFI firmware has its own submodule and wrapper over OpenSSL library (OpensslLib) in the CryptoPkg component. The main EDKII repository on Github is frequently updated and the developer community pays attention to security issues on a regular basis. But one of the main questions is how these fixes reflect on the supply chain of endpoint devices.
In many cases, firmware is a single point of failure between all the layers of the supply chain and the endpoint customer device.
We have previously highlighted repeatable failures related to delivering these fixes on endpoint devices even after vulnerabilities are known to the device vendor (“One month after Black Hat disclosure, HP's enterprise kit still unpatched”). But when it comes to the third-party-related code, it creates even more complicated problems around the delivery of fixes.
Microsoft recently highlighted in the “Digital Defense Report 2022”: 32% of firmware images analyzed contained at least 10 known critical vulnerabilities.
We also see this trend in our telemetry data confirming this is on the rise. Approximately 20% of firmware updates contain at least two or three known vulnerabilities (previously disclosed), according to Binarly Platform data (based on enterprise-grade vendors' study).
There is a significant decrease in the cost of deploying a firmware attack with a 1/N-day vulnerability compared to leveraging a new vulnerability (0-day).
Let’s take a closer look at Lenovo Thinkpad enterprise devices and how many different versions of OpenSSL are used in one firmware image.
As we can see, in the same firmware binary package at least three different versions of OpenSSL are in use -- 1.0.0a (2014), 1.0.2j (2018), 0.9.8zb (2014). The most recent OpenSSL version was released in 2018 which makes it four years out of date.
Many of the security-related firmware modules contain significantly outdated versions of OpenSSL. Some of them like InfineonTpmUpdateDxe contain code known to be vulnerable for at least eight (8) years. The InfineonTpmUpdateDxe module is responsible for updating the firmware of Trusted Platform Module (TPM) on the Infineon chip. This clearly indicates the supply chain problem with third-party dependencies when it looks like these dependencies never received an update, even for critical security issues.
The most recent version of OpenSSL which is used on Lenovo enterprise devices dates back to the summer of 2021. The graphic below displays all the versions of OpenSSL detected by the Binarly Platform in the wild (for the latest firmware updates) and the Linux Vendor Firmware Service (LVFS) public data feed:
These charts provide a good understanding of the big picture and the level of diversity regarding use of different versions of OpenSSL in the same device firmware code. To better understand this OpenSSL data, let's look at how different versions connect to the release date on the devices by major enterprise vendors.
From the Binarly OpenSSL data study, we can see that firmware often uses multiple versions of OpenSSL. The reasoning behind this is that the supply chain of third-party code depends on their own code base, which is often not available to device firmware developers. This creates an extra layer of supply chain complexity. Most of the OpenSSL dependencies are linked statically as libraries to specific firmware modules that create compile-time dependencies which are hard to identify without deep code analysis capabilities. Historically the problem within third-party code dependencies is not an easy issue to solve at the compiled code level.
The current industry approach is to generate hashes for the separate modules to connect with the particular release version numbers in order to connect the list of dependencies on the SBOM level. This approach works with open source projects (for example project Sigstore for verification) but on closed source ecosystems it will always fail. The hash provides integrity information, but it does not guarantee the SBOM contents and completeness for closed-source projects. In this sense, we see an urgent need for an extra layer of SBOM Validation when it comes to compiled code to validate on the binary level, the list of third-party dependency information that matches the actual SBOM provided by the vendor.
Integrity doesn't provide code level visibility, and scoping dependencies based on a binary module's hash is difficult. That's especially true when dependencies are indirect and buried in code abstraction layers.
Unfortunately there is no easy solution when it comes to binary code analysis and the industry needs to change its mindset on how we are thinking about supply chain security solutions based on SBOM. The list of the dependencies are constantly failing when it comes to the encapsulated third-party code. A ‘trust-but-verify’ approach is the best way to deal with SBOM failures and reduce supply chain risks.
Interested in learning more about Binarly Platform? Don't hesitate to contact us at fwhunt@binarly.io.
.svg)
