Lenovo Devices Using Outdated OpenSSL Versions
Reading Time: 2 minutes

Binarly a firmware protection platform discovered Dell, HP, and Lenovo using outdated versions of the  OpenSSL cryptographic library in analyzing their firmware images highlighting a supply chain risk.

The EFI Development Kit, also known as the EDK, is an open-source implementation of the Unified Extensible Firmware Interface (UEFI), which functions as an interface between the operating system and any embedded firmware.

The new firmware development environment, which is in its second iteration (EDK II), comes with a variety of tools. In particular, the tools are aimed at making security in FPGA designs easier. One such measure would be CryptoPkg, the cryptographic package from EDK, that includes services from OpenSSL.

The firmware images associated with Lenovo Thinkpad enterprise devices have been found to use three different versions of OpenSSL: 0.9.8zb, 1.0.0a, and 1.0.2j, all released in 2018 or later.

One of the firmware modules, InfineonTpmUpdateDxe, relied on OpenSSL version 0.9.8zb that was shipped on August 4, 2014.

Binarly in a technical write-up last week explained, “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 they appear as though they were never been updated, even for critical security issues.”

The diversity of OpenSSL versions aside, some of the firmware packages from Lenovo, Dell, and HP used even older versions than they should have. For instance, while HP’s following 0.9.8w is from 2009, Lenovo and Dell were using 2003’s 0.9.8l.

This is another example of how third-party code dependencies can introduce complexities in the supply chain ecosystem. In this case, the issue has to do with an instance of multiple versions of OpenSSL all coming from the same binary package, and firmware on a device.

Binarly pointed out the common difficulties of a Software Bill of Materials, which makes it more vulnerable by including compiled binary modules in the firmware.

After discovering that SBOM validation often doesn’t happen at compile time, the company is developing a new system to validate compiled code on the binary level. To do this, the team will create a list of third-party dependency information that matches what’s on the SBOMs provided by vendors.

The company added, “A trust-but-verify approach is the best way to deal with supply chain errors and limit the risks.”

Related Articles:
iSpoof Phone Spoofing Service – UK Police Nab 142 Individuals Linked
Turkish Authorities Seize FTX Founder Sam Bankman-Fried’s Assets
Why Ducktail Malware Is A Bigger Threat Than Ever?