Secure Boot is completely broken on 200+ models from 5 big device makers

FACEPALM GOES HERE — Secure Boot is completely broken on 200+ models from 5 big device makers Keys were labeled “DO NOT TRUST.” Nearly 500 device models use them anyway.

Dan Goodin – Jul 25, 2024 6:00 pm UTC Enlargesasha85ru | Getty Imates reader comments 118

In 2012, an industry-wide coalition of hardware and software makers adopted Secure Boot to protect against a long-looming security threat. The threat was the specter of malware that could infect the BIOS, the firmware that loaded the operating system each time a computer booted up. From there, it could remain immune to detection and removal and could load even before the OS and security apps did.

The threat of such BIOS-dwelling malware was largely theoretical and fueled in large part by the creation of ICLord Bioskit by a Chinese researcher in 2007. ICLord was a rootkit, a class of malware that gains and maintains stealthy root access by subverting key protections built into the operating system. The proof of concept demonstrated that such BIOS rootkits weren’t only feasible; they were also powerful. In 2011, the threat became a reality with the discovery of Mebromi, the first-known BIOS rootkit to be used in the wild.

Keenly aware of Mebromi and its potential for a devastating new class of attack, the Secure Boot architects hashed out a complex new way to shore up security in the pre-boot environment. Built into UEFIthe Unified Extensible Firmware Interface that would become the successor to BIOSSecure Boot used public-key cryptography to block the loading of any code that wasnt signed with a pre-approved digital signature. To this day, key players in securityamong themMicrosoftand theUS National Security Agencyregard Secure Boot as an important, if not essential, foundation of trust in securing devices in some of the most critical environments, including in industrial control and enterprise networks. An unlimited Secure Boot bypass

On Thursday, researchers from security firm Binarly revealed that Secure Boot is completely compromised on more than 200 device models sold by Acer, Dell, Gigabyte, Intel, and Supermicro. The cause: a cryptographic key underpinning Secure Boot on those models that was compromised in 2022. In a public GitHub repository committed in December of that year, someone working for multiple US-based device manufacturers published whats known as a platform key, the cryptographic key that forms the root-of-trust anchor between the hardware device and the firmware that runs on it. The repository was located at https://github.com/raywu-aaeon/Ryzen2000_4000.git, and it’s not clear when it was taken down.

The repository included the private portion of the platform key in encrypted form. The encrypted file, however, was protected by a four-character password, a decision that made it trivial for Binarly, and anyone else with even a passing curiosity, to crack the passcode and retrieve the corresponding plain text. The disclosure of the key went largely unnoticed until January 2023, when Binarly researchers found it while investigating a supply-chain incident. Now that the leak has come to light, security experts say it effectively torpedoes the security assurances offered by Secure Boot.

Its a big problem, said Martin Smolr, a malware analyst specializing in rootkits who reviewed the Binarly research and spoke to me about it. Its basically an unlimited Secure Boot bypass for these devices that use this platform key. So until device manufacturers or OEMs provide firmware updates, anyone can basically execute any malware or untrusted code during system boot. Of course, privileged access is required, but thats not a problem in many cases.

Binarly researchers said their scans of firmware images uncovered 215 devices that use the compromised key, which can be identified by the certificate serial number 55:fb:ef:87:81:23:00:84:47:17:0b:b3:cd:87:3a:f4. A table appearing at the end of this article lists each one.

The researchers soon discovered that the compromise of the key was just the beginning of a much bigger supply-chain breakdown that raises serious doubts about the integrity of Secure Boot on more than 300 additional device models from virtually all major device manufacturers. As is the case with the platform key compromised in the 2022 GitHub leak, an additional 21 platform keys contain the strings DO NOT SHIP or DO NOT TRUST. Enlarge / Test certificate provided by AMI.Binarly Page: 1 2 3 4 Next → reader comments 118 Dan Goodin Dan Goodin is Senior Security Editor at Ars Technica, where he oversees coverage of malware, computer espionage, botnets, hardware hacking, encryption, and passwords. In his spare time, he enjoys gardening, cooking, and following the independent music scene. Dan is based in San Francisco. Follow him at @dangoodin on Mastodon. Advertisement Promoted Comments jhodge No real issue – all the affected keys will be banned immediately, right? Right?!

Oh wait; no, they won’t because that would essentially brick a huge number of devices. Which is the issue we’ve seen with compromised code-signing and TLS keys in the past. Mathematically, PKI-based systems can be almost-perfectly secure. Practically, nobody is prepared to accept the practical consequences of revoking a key serving as a trust anchor for a large number of leaf nodes, so it’s just not done and we’re left with all sorts of half-measure workarounds.

example:
Leak of MSI UEFI signing keys stokes fears of doomsday supply chain attack With no easy way to revoke compromised keys, MSI, and its customers, are in a real pickle. arstechnica.com July 25, 2024 at 6:16 pm fuzzyfuzzyfungus It’s neat how all the vendor responses are of the "no problem; those are out of support and/or spun off into a sacrificial subsidiary" flavor.

I guess that’s what you sound like when the only exposure you care about is financial or legal; but that’s a clear middle finger and ‘won’t fix’.

(edit: re-read slightly more closely: in fairness to Supermicro they seem to be straightforwardly acknowledging that it’s in fact a problem. I’d certainly verify rather than trust that the most recent BIOS updates actually solve the problem; but they don’t seem to be disclaiming responsibility.

HP and Intel just seem way weirder on close reading: Intel’s spokesperson says "The distinction hereand why this isnt an Intel issue in currently shipped products and may be causing some confusionis the key in question was in the BIOS provided and generated by the system manufacturer, in this case AMI, for these server boards" despite the fact that these are Intel server boards, from when Intel still made motherboards(or at least designed and contract-manufactured or relatively-closely-supervised ODM-ed them; not 100% sure what the arangement was). Did they license some firmware from AMI? Apparently, very common thing to do. Was AMI the actual board vendor and these were just Intel branded? No, AMI doesn’t do board manufacturing. Did AMI release a "AMI UEFI for Intel Server Motherboards" product? Not that I’m aware of or able to find any evidence of. Clearly Intel licensed code from AMI; but she’s talking like this was AMI’s show; rather than AMI being a supplier. HP, for their part, says it does not impact "any commercial devices either within service life or running on HP BIOS". Does this mean that some HP commercial devices don’t run HP BIOSes; but do run AMI-derived firmware? I wouldn’t be totally surprised if HP has released at least something that supports coreboot, either for some hyperscaler or for a specialty customer, but a coreboot user wouldn’t be using AMI secure boot stuff(nor would they likely show up in publicly available firmware; that’d be a very special order type thing); which makes their denial sound like it alludes to the existence of HP commercial systems running non-HP firmware(unless "HP BIOS" is just a branding thing adopted for certain newer HP firmware; and it’s just a more cryptic way of saying that nothing in support is affected). Very odd.

Lenovo is a straightforward "not in support, we don’t care"; Fujitsu is a "arm’s length subsidiary’s problem now; they say not in support, we don’t care".) July 25, 2024 at 6:32 pm Channel Ars Technica ← Previous story Next story → Related Stories Today on Ars