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^[1]
cryptographic library, underscoring a supply chain risk.

EFI Development Kit, aka EDK^[2], is an open source
implementation of the Unified Extensible Firmware Interface
(UEFI^[3]), 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^[4]
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^[5]) on the Infineon chip,”
Binarly explained^[6]
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^[7]) 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.”