[German]A firmware analysis by security vendor Binarly has revealed that devices from Dell, HP and Lenovo use outdated versions of the OpenSSL encryption library in their UEFI implementations. This poses a risk, as encryption could be broken and the update supply chain compromised. The outdated OpenSSL versions gets onto these machines through an EFI Development Kit (EDK). Currently, however, there doesn't seem to be a solution for how device manufacturers can get a handle on the problem of using up to three outdated (some dating back to 2014) OpenSSL versions even in updated UEFI firmware.
Advertising
OpenSSL and the vulnerabilities
OpenSSL is a widely used code library that enables secure communication over the Internet. OpenSSL includes implementations of the network protocols and various ciphers, as well as the openssl command-line program for requesting, generating, and managing certificates (see). In early November 2022, there was a security warning about two vulnerabilities in this library and a security update to OpenSSL 3.0.7 (see OpenSSL 3.0.7 with security fixes released).
It should be noted, however, that these vulnerabilities only affected OpenSSL 3.0.0; older versions such as OpenSSL 1.0.2 and 1.1.1 are not affected by the above security issue.
Do devices use OpenSSL?
The interesting question now is where OpenSSL is used in devices and whether there might be a problem with outdated library versions. There is an EFI Development Kit (EDK) as an open source implementation of the Unified Extensible Firmware Interface (UEFI). This is used by device manufacturers to act as an interface between the operating system and the firmware embedded in the device hardware. It is now known that version 2 (EDK II) of the EFI Development Kit uses the OpenSSL library in the CryptoPkg encryption package.
That was the point when security firm Binarly wondered if the UEFI implementations of popular device manufacturers like Dell, HP and Lenovo might be using outdated OpenSSL libraries in the firmware. The security team wanted to know what the update situation was with UEFI firmware and how widespread the use of OpenSSL versions is in the firmware context. This is because Microsoft stated in the Defense Report 2022 that 32% of the analyzed firmware images have at least ten critical vulnerabilities.
Old OpenSSL versions found
An analysis of firmware images for devices from Dell, HP and Lenovo has revealed the presence of outdated versions of the OpenSSL encryption library, which poses a risk in the supply chain. This document states that Lenovo Thinkpad Enterprise devices use at least three different versions of OpenSSL in the same firmware binary package.
Advertising
OpenSSL versions in Lenovo firmware
The table above shows the OpenSSL versions 1.0.0a (2014), 1.0.2j (2018) and 0.9.8zb (2014) used, which were found in various UEFI modules. The most recent OpenSSL version 1.0.2j was released in 2018, making it four years old. The OpenSSL version used in the Infinion TPM update module (for installing updates in the TPM chip) even dates back to 2014 and has known vulnerabilities.
The discovery already showed two things: First, the firmware of these examined Lenovo devices has not received any updates of the OpenSSL libraries by the manufacturer for many years. And there are major supply chain risks lurking in the firmware if the update modules for the TPM module have known vulnerabilities for eight years. The latest version of OpenSSL used on Lenovo enterprise devices is from summer 2021.
OpenSSL versions used by Lenovo, Dell, HP
The security researchers then also analyzed devices from Dell and HP with regard to their UEFI firmware and the OpenSSL versions used. The above table published in this article shows that outdated OpenSSL libraries are used there as well.
The Binarly OpenSSL data study shows that firmware often uses multiple versions of OpenSSL. The reason, according to Binarly, is that the supply chain for third-party code depends on their own code base. This code base is often not available to device firmware developers. This adds another layer of complexity to the supply chain. Most OpenSSL dependencies are statically linked as libraries to specific firmware modules that create dependencies at compile time. These are difficult to detect without deep code analysis capabilities. The problem of third-party code dependencies at the compiled code level is not easily solved from this perspective.
Binarly does describe in this article the current industry approach of generating hashes for each module to associate with their respective version numbers to create the SBOM-level dependency list. But the observation is that this approach does work for open-source projects (where the code is, after all, visible). But for closed-source ecosystems, the approach will always fail. The hash provides integrity information, but it does not guarantee the content and completeness of the SBOM for closed-source projects.
Binarly sees an urgent need for an additional layer of SBOM validation when it comes to compiled code, to validate at the binary level the list of third-party dependency information that matches the vendor-provided SBOM. (via)
