Secure Boot rendered useless, over 200 PC models from different makers are affected

zohaibahd

Posts: 934   +19
Staff
WTF?! If you thought your laptop, desktop, or server was protected by Secure Boot, think again. A new vulnerability dubbed "PKfail" has left Secure Boot wide open on hundreds of PC and devices across several major tech brands. Researchers at cybersecurity firm Binarly just dropped a bombshell report showing how a leaked cryptographic key has essentially nuked the security guarantees of Secure Boot for over 200 product models.

Secure Boot is a security standard created by PC industry members to ensure that a device can only boot up using software verified and trusted by the respective OEM. This new security breach stems from someone working for multiple US manufacturers accidentally leaking the "platform key" for Secure Boot in late 2022.

This key is the critical root-of-trust that underpins the entire Secure Boot process on devices from vendors like Acer, Dell, Gigabyte, Intel, and Supermicro. According to a report from Ars Technica, an employee posted source code containing the encrypted platform key to a public GitHub repo. They protected it with a laughably weak 4-character password that was easily cracked.

While the leak initially flew under the radar, Binarly's researchers stumbled upon it in January 2023. Their findings reveal that this compromised platform key was being disturbingly reused across hundreds of different product lines from multiple big-name tech brands. It's also a cross-silicon issue, as it affects both x86 and Arm devices.

Essentially, this means malicious actors can bypass Secure Boot by signing malicious code and load up nasty firmware implants like the infamous BlackLotus. The findings are especially concerning given Microsoft has made Secure Boot a requirement for Windows 11 and has been pushing the technology for years to secure systems against BIOS rootkits.

The fallout has been a decade in the making, too. Binarly's analysis of UEFI firmware images stretching back to 2012 found over 10% were impacted by using these untrusted keys, instead of manufacturer-generated secure ones as intended. Even looking at just the past 4 years, 8% of firmware still had the issue.

This is a brutal supply chain failure, exposing how sloppily some vendors have handled critical platform security. Issues range from reusing the same keys across consumer and enterprise device lines, shipping products with non-production cryptographic material, and failing to rotate keys regularly. Binarly highlighted these security problems related to device supply chain security that led to this breach.

For device owners and IT admins, Binarly advises first checking if your equipment is listed in their vulnerability advisory and quickly applying any related firmware patches from your vendor.

Furthermore, the firm notes that device vendors should ensure they generate and manage the platform key following best practices for cryptographic key management, such as using Hardware Security Modules. They should also replace any test keys provided with securely generated keys.

Masthead credit: FlyD

Permalink to story:

 
This is more of a cultural problem than it is a technical issue. The decision makers involved here simply do not care. No amount of policy changes will cause change unless there are absolutely massive fines imposed to which the likes of have never been seen before.
 
On the one hand this is a pretty bad fail. On the other hand, secure boot is one of those things that always toed the line between security and DRM, so maybe it's not a terrible thing to find out that so many manufacturers aren't all that concerned about it. Even so, for those depending on it to help keep their devices safe, this is not good news.
 
Now fix your broken UEFI NTFS boot driver. Rufus changelog.

"Update UEFI:NTFS to latest (now always uses the ntfs-3g driver, rather than the buggy AMI NTFS one)"

Maybe you guys can fix this now instead of third party persons doing it.
 
Once again, another claim by the mfg's that is false .... we need a law on this one and a few more as well ....
Once again, another false claim by an Internet poster. This is a problem with the key, not Secure Boot itself. The headline is like claiming physical locks don't work because someone lost their house key.
 
The decision makers involved here simply do not care.

On the other hand, secure boot is one of those things that always toed the line between security and DRM

Yes and yes. The relevant decision makers here are motherboard purchasers, many of whom are likely downright hostile to the idea of a motherboard/PC that runs only Microsoft-approved software. I expect the effort that went into implementing this "feature" was the bare minimum, with a side of "our customers can break this if they want to, right?"
 
Secure boot was always absurdly easy to by pass anyway, I don't know what anyone is surprised. All of these long term supported security features only need on fatal flaw in them to make them useless.

Security through obscurity. If they have several different methods and it's upto the user to decide which one they use then you divide the hackers. Once you mandate something you make it the sole point of attack then you attract everyone.
 
I always disable Secure Boot, and Linux is my main OS. Linux may not be impenetrable, but at least, it's much more safer and efficient than Windows.
 
I always disable Secure Boot, and Linux is my main OS. Linux may not be impenetrable, but at least, it's much more safer and efficient than Windows.
many of whom are likely downright hostile to the idea of a motherboard/PC that runs only Microsoft-approved software
To be fair, you can use Secure Boot with Linux. But, there are plenty of systems that come with a Microsoft signed key which require care if one is going to fiddle with that. I suspect the reason it is primarily used in conjunction with Windows is probably due to the nature of how the different OSes are distributed, where they are used, and Microsoft's requirements around secure boot, as opposed to the Secure Boot feature itself.

In theory, the idea of secure boot makes sense - only boot the code that is on some predetermined allow list (or not on some deny list) - but the practical side leaves a lot to be desired. This is partly unavoidable, the very nature of FOSS makes it nigh impossible to whitelist all the different BSD and Linux distros and versions out there, let alone agree on a certificate authority for them all which could, in fact, vet the software and supply chain. Getting a certificate on the code isn't the problem: it's trusting that certificate, at scale, in all the diverse corners of the supply chain, for both the software and hardware sides, that is the problem

At the end of the day, secure boot doesn't change the old adage: if you don't have physical security over your device, you should assume it is compromised if it is in the physical hands of an attacker. Secure boot and full disk encryption can make offline attacks really difficult, but not impossible. As for online attacks, well, your device is already booted and decrypted on the fly, so any malware that gets through is unlikely to be defeated by secure boot (full disk encryption ransomware is a different beast as it typically has to supplant the OS in some ways, but that type of ransomware is almost a decade old at this point and today's variants are quite sophisticated). Thus, apart from businesses which want to feel better about themselves (and typically feel better about their own lock-in to the Microsoft ecosystem), I don't know how much security secure boot can actually buy you.
 
Well with secure boot you have the luxury also to have users being not able to log in to windows all the sudden. So we have to find the key for the them in our system. And then hopefully you can give the long key to the user and hope that the drive is not completely toast. Usually they work but the reason for this hickup in UEFI or the reason why the disk was not found, is yet not entirely known. But still, a fun day at work that really feels meaningful. All we do is working in slow cloud webbrowsers, implementing new security features and lower our production for each change. Very long passwords, very short access windows....I mean it has become a joke. And still, the most secure way is not using computers....at all. All layers of security is one day completely useless. It is a crazy world, almost a clownworld. But dont fret, AI will solve everything - the new tech will erase all yesterdays issues. Rinse and repeat, just hop on the next hypetrain...there is room for everybody, it will eventually take us to the next trainwreck scenario but rest assure....you are given something for your investment....a new headache! :)
 
So I was forced to enable secure boot to upgrade to 11 to prevent security vulnerabilities just to find out secure boot is now completely useless.... Thanks Microsoft.
 
Now fix your broken UEFI NTFS boot driver. Rufus changelog.

"Update UEFI:NTFS to latest (now always uses the ntfs-3g driver, rather than the buggy AMI NTFS one)"

Maybe you guys can fix this now instead of third party persons doing it.
I don't understand, did Rufus fix this or not!?
 
Back