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

Cyber Security

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.

OpenSSL Versions

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

Products You May Like

Articles You May Like

Intel Announces New Initiatives for AI PC Developers and Hardware Vendors
U.S. Sanctions 3 Cryptocurrency Exchanges for Helping Russia Evade Sanctions
Big week for tech IPOs Reddit, Astera boosts Morgan Stanley after extended lull
Honor MagicBook X14 Pro (2024), MagicBook X16 Pro (2024) to Go on Sale in India in April; Pre-Order Offers Revealed
Microsoft, Meta and X Join Fortnite Maker Epic Games’ Battle Against Apple

Leave a Reply

Your email address will not be published. Required fields are marked *