We have frequently covered the topic of supply chain problems related to reference code when silicon vendors ship vulnerable code to the entire ecosystem. These vulnerabilities typically require a significant amount of time and effort to get fixed since they impact all the vendors that incorporate the vulnerable code into the firmware on their devices.
In my recent blog post on the BlackLotus UEFI bootkit, we discussed how big a problem the firmware supply chain poses to Microsoft Windows bootloaders, showing how the BatonDrop (CVE-2022-21894) vulnerability can bypass both device attestation and secure boot.
My experience with the analysis and detection of rootkits and bootkits goes back more than 20 years. In the early 2000s, the main challenge was dealing with infected machines when rootkits and bootkits modified the operating system kernel to conceal malicious components. It was such a fun time reverse engineering advanced threats in the good old days that I co-wrote "Rootkits and Bootkits: Reversing Modern Malware and Next Generation Threats," a book full of the most interesting stories of our time going down the rabbit hole of advanced malware.
The Binarly team is constantly researching ways to automate our proprietary deep code inspection technology to improve the discovery of different classes of bugs within system firmware. The Binarly efiXplorer team has decades of experience in program analysis and automation, enabling us to develop unique binary analysis techniques and technologies internally.
Speculative execution mitigations have been discussed for some time, but most of the focus has been at the operating system level in order to adopt them in software stacks. What is happening at the firmware level? When it comes to applying these mitigations, how does the industry take advantage of them, and who coordinates their adoption specifically into the firmware? These are all good questions, but unfortunately no positive news can be shared.
Almost a year ago, while describing our company mission and the limitations of available solutions for detecting firmware threats, we discussed our initial vision around binary code inspection for detecting firmware threats and vulnerabilities (See: Why Firmware Integrity Is Insufficient For Effective Threat Detection And Hunting).
A month ago, Binarly’s security research team managed the coordinated disclosure of 16 high impact vulnerabilities in HP devices and 23 additional security defects impacting major enterprise vendors. In less than a year, Binarly disclosed 42 high severity vulnerabilities haunting the UEFI firmware ecosystem, all serious enough to cause arbitrary code execution in System Management Mode (SMM).
Today, Binarly’s security research lab announced the discovery and coordinated disclosure of 16 high-severity vulnerabilities in various implementations of UEFI firmware affecting multiple enterprise products from HP, including laptops, desktops, point-of-sale systems, and edge computing nodes.
In our previous blog “The Firmware Supply Chain Security is broken Can we fix it”, we delved deep into the challenges of the firmware ecosystem by introducing the supply chain "race condition" paradigm.
At the beginning of December, Binarly was very active in spreading the word about the problems in the firmware supply chain ecosystem at multiple security conferences. Alex Matrosov, the Binarly CEO, gave a keynote entitled “The Evolution of Threat Actors: Firmware is the Next Frontier” at AVAR conference in which he focused on the evolving threats coming from historically overlooked places below the operating system.
In our previous two blogs, Firmware Supply Chain is Hard(coded) and Attacking (pre)EFI Ecosystem, we described in detail four high severity vulnerabilities that impacted the UEFI system firmware and put a large number of enterprise devices at high risk.
