Dell, HP, and Lenovo Devices Found Using Outdated OpenSSL Versions

An analysis of firmware images across devices from Dell, HP, and Lenovo has revealed the presence of outdated versions of the OpenSSL cryptographic library, underscoring a supply chain risk.

EFI Development Kit, aka EDK, is an open-source implementation of the Unified Extensible Firmware Interface (UEFI), which functions as an interface between the operating system and the firmware embedded in the device’s hardware.

The firmware development environment, which is in its second iteration (EDK II), comes with its own cryptographic package called CryptoPkg that, in turn, uses services from the OpenSSL project.

The firmware image associated with Lenovo Thinkpad enterprise devices was found to use three different versions of OpenSSL: 0.9.8zb, 1.0.0a, and 1.0.2j, the last of which were released in 2018.

Moreover, one of the firmware modules, InfineonTpmUpdateDxe, relied on OpenSSL version 0.9.8zb, which was shipped on August 4, 2014.

The InfineonTpmUpdateDxe module updates the firmware of the Trusted Platform Module (TPM) on the Infineon chip.

OpenSSL Versions

This clearly indicates the supply chain problem with third-party dependencies when it looks like they never received an update, even for critical security issues.

The diversity of OpenSSL versions aside, some of the firmware packages from Lenovo and Dell utilized an even older version (0.9.8l), which came out on November 5, 2009. HP’s firmware code, likewise, used a 10-year-old version of the library (0.9.8w).

The fact that the device firmware uses multiple versions of OpenSSL in the same binary package highlights how third-party code dependencies can introduce more complexities in the supply chain ecosystem.

It was pointed out the weaknesses in what’s called a Software Bill of Materials (SBOM) that arise from integrating compiled binary modules (aka closed source) in the firmware.

There is 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.

A ‘trust-but-verify’ approach is the best way to deal with SBOM failures and reduce supply chain risks.

Source: THN, Binarly