SoylentNews

hubie [soylentnews.org] writes:

Keys were labeled "DO NOT TRUST." Nearly 500 device models use them anyway. [arstechnica.com]

In 2012, an industry-wide coalition of hardware and software makers adopted Secure Boot [uefi.org] 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 [csdn.net] by a Chinese researcher in 2007. ICLord was a rootkit [wikipedia.org], 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 [theregister.com], the first-known BIOS rootkit to be used in the wild.

Keenly aware of Mebromi [uefi.org] 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 UEFI—the Unified Extensible Firmware Interface that would become the successor to BIOS—Secure Boot used public-key cryptography to block the loading of any code that wasn't signed with a pre-approved digital signature. [...]

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 what's 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, [github.com] 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.

[...] 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."

[...] People who want to know if their Windows device uses one of the test platform keys can run the following powershell command:

> [System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI
PK).bytes) -match "DO NOT TRUST|DO NOT SHIP"
True

Linux users can detect one of the test certificates by displaying the content of the PK variable:

$ efi-readvar -v PK
Variable PK, length 862
PK: List 0, type X509
Signature 0, size 834, owner 26dc4851-195f-4ae1-9a19-
fbf883bbb35e
Subject:
CN=DO NOT TRUST - AMI Test PK
Issuer:
CN=DO NOT TRUST - AMI Test PK

There's little that users of an affected device can do other than install a patch if one becomes available from the manufacturer. In the meantime, it's worth remembering that Secure Boot has a history of not living up to its promises. The most recent reminder came late last year with the disclosure of LogoFAIL, a constellation of image-parsing vulnerabilities in UEFI libraries from just about every device maker. By replacing the legitimate logo images with identical-looking ones that have been specially crafted to exploit these bugs, LogoFAIL makes it possible to execute malicious code at the most sensitive stage of the boot process, which is known as DXE, short for Driver Execution Environment.

"My takeaway is 'yup, [manufacturers] still screw up Secure Boot, this time due to lazy key management,' but it wasn't obviously a change in how I see the world (secure boot being a fig leaf security measure in many cases)," HD Moore, a firmware security expert and CTO and co-founder at runZero, said after reading the Binarly report. "The story is that the whole UEFI supply chain is a hot mess and hasn't improved much since 2016."

The 215 affected devices are listed at the end of TFA [arstechnica.com].

Original Submission