Pierluigi Paganini
November 26, 2022
Binarly researchers discovered that devices from Dell, HP, and Lenovo are still using outdated versions of the OpenSSL cryptographic library.
The OpenSSL software library allows secure communications over computer networks against eavesdropping or need to identify the party at the other end. OpenSSL contains an open-source implementation of the Secure Sockets Layer (SSL) and Transport Layer Security (TLS) protocols.
The researchers discovered the issue by analyzing firmware images used devices from the above manufacturers.
The experts analyzed one of the core frameworks EDKII used as a part of any UEFI firmware which has its own submodule and wrapper over the OpenSSL library (OpensslLib) in the CryptoPkg component.
EDK II is a modern, feature-rich, cross-platform firmware development environment for the UEFI and UEFI Platform Initialization (PI) specifications.
The main EDKII repository is hosted on Github and is frequently updated.
The experts first analyzed Lenovo Thinkpad enterprise devices and discovered that they used different versions of OpenSSL in the firmware image.
Lenovo Thinkpad enterprise devices used three different versions of OpenSSL: 0.9.8zb, 1.0.0a, and 1.0.2j. The most recent OpenSSL version was released in 2018.
“Many of the security-related firmware modules contain significantly outdated versions of OpenSSL. Some of them like InfineonTpmUpdateDxe contain code known to be vulnerable for at least eight (8) years.” reads the report published by Binarly. “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 it looks like these dependencies never received an update, even for critical security issues.”
One of the firmware modules named InfineonTpmUpdateDxe uses the OpenSSL version 0.9.8zb that was released on August 4, 2014.
The researchers discovered that most recent OpenSSL version is used by on Lenovo enterprise devices and dates back to the summer of 2021.
The following image reports for each vendor all the versions of OpenSSL detected by the Binarly Platform in the wild:
The experts pointed out that the same device firmware code often rely on different versions of OpenSSL.
The reason for this design choice is that the supply chain of third-party code depends on their own code base, which is often not available to device firmware developers. The researchers explained that this introduces an extra layer of supply chain complexity.
“Most of the OpenSSL dependencies are linked statically as libraries to specific firmware modules that create compile-time dependencies which are hard to identify without deep code analysis capabilities.” continues the report. “Historically the problem within third-party code dependencies is not an easy issue to solve at the compiled code level.”
The experts noticed that devices from Dell and Lenovo relied on version 0.9.8l that dates back to 2009.
Some Lenovo devices used the version 1.0.0a that dates back 2010, while the three vendors (Lenovo, Dell, HP) were observed using version 0.9.8w that dates back 2012.
“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,” concludes the report. “A ‘trust-but-verify’ approach is the best way to deal with SBOM failures and reduce supply chain risks.”
Follow me on Twitter: @securityaffairs and Facebook and Mastodon
| [adrotate banner=”9″] | [adrotate banner=”12″] |
(SecurityAffairs – hacking, firmware)
[adrotate banner=”5″]
[adrotate banner=”13″]
