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, makes use of services from the OpenSSL project.

Per firmware security company Binarly, 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 was released in 2018.

What’s more, one of the firmware modules named InfineonTpmUpdateDxe relied on OpenSSL version 0.9.8zb that was shipped on August 4, 2014.

“The InfineonTpmUpdateDxe module is responsible for updating the firmware of Trusted Platform Module (TPM) on the Infineon chip,” Binarly explained in a technical write-up last week.

“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 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.

Binarly further pointed out the weaknesses in what’s called a Software Bill of Materials (SBOM) that arises as a result of integrating compiled binary modules (aka closed source) in the firmware.

“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,” the company said.

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

Found this article interesting? Follow THN on Facebook, Twitter  and LinkedIn to read more exclusive content we post.