Secure Boot Is Completely Broken On 200+ Models From 5 Big Device Makers (arstechnica.com) 63
An anonymous reader quotes a report from Ars Technica, written by Dan Goodin: 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..., 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.
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." These keys were created by AMI, one of the three main providers of software developer kits that device makers use to customize their UEFI firmware so it will run on their specific hardware configurations. As the strings suggest, the keys were never intended to be used in production systems. Instead, AMI provided them to customers or prospective customers for testing. For reasons that aren't clear, the test keys made their way into devices from a nearly inexhaustive roster of makers. In addition to the five makers mentioned earlier, they include Aopen, Foremelife, Fujitsu, HP, Lenovo, and Supermicro.
Cryptographic key management best practices call for credentials such as production platform keys to be unique for every product line or, at a minimum, to be unique to a given device manufacturer. Best practices also dictate that keys should be rotated periodically. The test keys discovered by Binarly, by contrast, were shared for more than a decade among more than a dozen independent device makers. The result is that the keys can no longer be trusted because the private portion of them is an open industry secret. Binarly has named its discovery PKfail in recognition of the massive supply-chain snafu resulting from the industry-wide failure to properly manage platform keys. The report is available here. Proof-of-concept videos are here and here. Binarly has provided a scanning tool here. "It's a big problem," said Martin Smolar, a malware analyst specializing in rootkits who reviewed the Binarly research. "It's 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 that's not a problem in many cases."
Binarly founder and CEO Alex Matrosov added: "Imagine all the people in an apartment building have the same front door lock and key. If anyone loses the key, it could be a problem for the entire building. But what if things are even worse and other buildings have the same lock and the keys?"
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." These keys were created by AMI, one of the three main providers of software developer kits that device makers use to customize their UEFI firmware so it will run on their specific hardware configurations. As the strings suggest, the keys were never intended to be used in production systems. Instead, AMI provided them to customers or prospective customers for testing. For reasons that aren't clear, the test keys made their way into devices from a nearly inexhaustive roster of makers. In addition to the five makers mentioned earlier, they include Aopen, Foremelife, Fujitsu, HP, Lenovo, and Supermicro.
Cryptographic key management best practices call for credentials such as production platform keys to be unique for every product line or, at a minimum, to be unique to a given device manufacturer. Best practices also dictate that keys should be rotated periodically. The test keys discovered by Binarly, by contrast, were shared for more than a decade among more than a dozen independent device makers. The result is that the keys can no longer be trusted because the private portion of them is an open industry secret. Binarly has named its discovery PKfail in recognition of the massive supply-chain snafu resulting from the industry-wide failure to properly manage platform keys. The report is available here. Proof-of-concept videos are here and here. Binarly has provided a scanning tool here. "It's a big problem," said Martin Smolar, a malware analyst specializing in rootkits who reviewed the Binarly research. "It's 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 that's not a problem in many cases."
Binarly founder and CEO Alex Matrosov added: "Imagine all the people in an apartment building have the same front door lock and key. If anyone loses the key, it could be a problem for the entire building. But what if things are even worse and other buildings have the same lock and the keys?"
So many inevitable things happening recently (Score:3, Interesting)
With the clownstroke issue and this, the only thing that's left is AWS irreversibly deleting all S3 buckets.
Re: (Score:2)
Foreshadow well you do young padawan.
Comment removed (Score:5, Funny)
Re: (Score:3)
Someone calling me young padawan is like getting carded while buying beer despite the grey hairs and bald spot.
Oh god I've been on slashdot for over a quarter of a century.
Re:So many inevitable things happening recently (Score:4, Funny)
Someone calling me young padawan is like getting carded while buying beer despite the grey hairs and bald spot.
Oh god I've been on slashdot for over a quarter of a century.
Get off my lawn. :-D
Re: (Score:2)
Kids!
Re: (Score:2)
Re:So many inevitable things happening recently (Score:5, Funny)
The systemd team is working on that.
Re:So many inevitable things happening recently (Score:4, Interesting)
Reading TFS, I realize that secure has always been broken. As soon as you share a private key across many devices or entities, possibilities of leaks become so great that the web of trust becomes broken.
For example, I am the only person knowing the private keys for gpg signing I use. My web server is the only device the cert private key resides on, etc.
So, secure boot is obviously PKI done wrong.
Re: (Score:3)
So, secure boot is obviously PKI done wrong.
No, it's PKI not being used for what it was designed for.
The whole point of the Platform Key in Secure Boot (on paper) was that it was the device owner's key. Which would be enrolled upon first boot after the delivery of the system to it's owner. If Secure Boot was implemented properly, you'd buy a new device and the first thing that device would do is ask for a flash drive or yubikey, etc. with your Platform Key.
Of course the industry realized that their training of entitled ID10-Ts over the years wou
Re: (Score:2)
The whole point of the Platform Key in Secure Boot (on paper) was that it was the device owner's key. Which would be enrolled upon first boot after the delivery of the system to it's owner.
And that would be PKI done right and as it was intended, only the user has the private key.
Thanks! I didn't know Secure Boot was designed like that from the start.
What you say doesn't surprise me at all although. I worked for a "Secure Government Online" project and we designed it so each user would generate and own his own private key but in the end, the same kind of shortcuts were taken due to exactly the concerns; too complicated for the average user!
So in the end, private keys were generated and kept on
Re: (Score:2)
We often heard about how and what should be taught in schools about IT. Maybe the first thing should be the importance of understanding what a private key is. Pretty simple IMHO, you generate the private key yourself and never share it, if you lose it, you need to generate and use a new one.
We are stuck because the security systems are not designed with enough consideration of human psychology.
The platform key idea asks for in effect a physical key for each machine to keep safe. For it to work without too much technical know-how from the users, such key should have been a physical device bundled together with the motherboard or the brand-name PC when sold. If you ask the users to prepare the platform key storage media by themselves, it is doomed to failure. Nobody buy locks and keys separat
Re: (Score:2)
Yeah I don't buy it. I think the idea the owner of the hardware was every really expected have the platform keys was a polite fiction used manage the public and undercut the arguments and warnings by handful of influential people who did not want to see in the PC platform.
It was always being pushed by orgs like Microsoft and it was always about having some assurance (however still flawed) your machine was/is running code "they" trust and not so much about code "you" trust.
Big tech was ALWAYS jealous of bot
Re: (Score:2)
The idea was never to have every use enrol their own Platform Key (PK). The idea was always to have the manufacturer load a PK along with the OS. Most computers ship with an OS pre-installed.
This isn't really a supply chain attack either. These keys were distributed by AMI, the EUFI vendor. There was little effort made to protect them because they were clearly marked "DO NOT SHIP", for testing purposes only. The screw up is that the OEMs didn't heed that warning and generate their own PKs, they just used th
Re: (Score:3)
Re: (Score:2)
With the clownstroke issue and this, the only thing that's left is AWS irreversibly deleting all S3 buckets.
But Amazon assures me that my S3 data has 99.999999999% "durability", so that something like that must be simply impossible! (Right?)
Re:So many inevitable things happening recently (Score:5, Informative)
If you really want security, I.e. the paranoid kind, install only your own key, and resign your OS's bootloader with it. You'll have to resign it anytime it gets updated. (Easy for Linux users as it's just shim for most people, Windows users have an entire directory structure, including font files, to resign each time.)
INB4 "That's a bunch of complicated hex editor crap!": Nope, even devices like the Dell Venue 11 Pro from 2013 have a graphical UI in their firmware for changing the Secure Boot Keys.
About the only exception to that (as I've already mentioned) is Microsoft Surface devices past the Surface 4. Those use Microsoft's own custom UEFI that doesn't allow the device owner to change the keys. They only have the choice to allow third party signers (Microsoft approved Linux distros) or to disable Secure Boot entirely. (Funny, how the father of Secure Boot thinks that only their security matters....)
Re: (Score:2)
I would say that the answer is not trying to wrangle SecureBoot to handle your and only your signature, as that is both a pain and highly limited compared to a strategy that is actually designed for individual protection (e.g. if someone replaces your initramfs, SecureBoot will not care, someone somehow manages to disable SecureBoot, you won't notice at the userspace level as things will just boot and act like they should, if you *only* do secureboot).
So using LUKS with TPM sealed key to a certain set of PC
Re: (Score:2)
Having a system that can boot without the user having to enter a decryption key is dangerous... You're relying on all of the various components working as advertised and continuing to do so. It's effectively obfuscation rather than encryption.
An attacker who steals a laptop which boots like this has a variety of options including hardware hacks to try extracting the keys, or simply keeping the laptop powered off until a new 0day vulnerability is discovered, then powering it up and exploiting it.
If the decry
Re: (Score:2)
When you have a few hundred systems, you can not possibly require keyboard interactive process to get booting.
SecureBoot alone is even weaker.
LUKS with TPM2 unsealed decryption can be pretty robust. You hit 'e' in grub to add 'rd.break=cmdline'? You just made PCR8 change and the disk can't decrypt. You pulled the disk out and modify the initramfs? You just caused PCR9 change and the disk can't be decrypted. You boot an alternate chain of tooling? You extended PCR7 away from being able to decrypt the d
Re: (Score:2)
When it comes to end user devices, each of those few hundred systems has exactly one user who's responsible for entering the key at bootup and is physically present in order to actually use the machine.
Servers that actually need to boot unattended are different. They typically sit in access controlled data centers so the chance of them being physically stolen is orders of magnitude lower. Encrypting the disk is of far less value, and only mitigates the slim chances of someone breaking into the datacenter or
Re: (Score:2)
The reasons can be inferred... (Score:4, Interesting)
Instead, AMI provided them to customers or prospective customers for testing. For reasons that aren't clear, the test keys made their way into devices from a nearly inexhaustive roster of makers.
One possible explanation is that AMI provided the keys for testing purposes, but as soon as the client discovered the testing software worked, cancelled the (prospective) deal with AMI and shipped the testing code instead. Shipping devices with "prototype" code is very, very common in the hardware industry.
Re:The reasons can be inferred... (Score:4, Informative)
When it comes to kits like that, a "prototype" can also be considered a "reference platform". Nothing particularly wrong with sticking to the reference. Saves you from adding new bugs.
The whole test keys problem is probably mainly ignorance, not reading docs, combined with some laziness, passing the buck. It gets buried then no one knows because it just works.
Re: (Score:2)
Not worth the effort because most customers wouldn't notice...
Secure boot supported? tick box, move onto next feature.
It's why you see so many products that support "encryption (tick box)" but then do stupid things that renders the encryption useless, like not bothering to validate the host keys.
Re: (Score:2)
Unfortunately, that is a very plausible explanation.
Re: (Score:2)
The Keys were labeled "DO NOT TRUST.".
So yes, probably for testing. And yet nobody actually seem to have read the instructions and just went with it.
So thats a huge development fail, at the very least.
Comment removed (Score:4, Funny)
We told them so (Score:3)
/. article comments from when Secure Boot was being implemented were full of warnings that these sorts of problems were inevitable.
It's a hack to do poor security with cheap hardware. And woe is you if you got Crowdstruck with Secure Boot and Bitlocker.
Re: (Score:3)
Those are the PNs for a number of top-of-the-line multi-thousand-dollar motherboards that went into leading-edge servers and workstations when they came out. The AS-4124, to name the 1st SM chassis, is designed to host 8 A100 GPUs plus 400Gbps of network connectivity. A midrange cpu+memory setup, (say, 2x40 Epyc Rome cores + 512G memory) before you added any
Re: (Score:2)
I am still convinced it has nothing to do with the security of the user at all, but instead is intended as a basis of DRM.
Get your own key (Score:3, Informative)
Both PK and KEK used by Secure Boot are user-replaceable and I generated and installed my own keys within the first day of owning my ThinkPad. It's just common sense. Why on Earth would you allow keys issued by a 3rd party to remain on your system beyond the setup phase?
Re: (Score:2)
Indeed, from my readings of the Secure Boot docs, this appears to have been the design intent. The OEM's PK is provided as a convenience to get Certain Commercial Software initially running on the system. But the Secure Boot design appears to expect you, as the new owner of the machine, to replace the OEM's PK with your own, and use it to sign the KEKs and DB keys o
Re: (Score:2)
I disagree, the design point is exactly to measure "well known operating system from reputable vendor". The UEFI hosted key material isn't used to measure user space in any implementation I'm aware of, and is not by itself tamper evident, which would be a critical component for security but is omitted from SecureBoot design.
Using disk encryption with keys signed to TPM PCRs and a chain of trust that properly extends the PCRs up to the point of decrypting the disk is really what is designed to provide more s
Re: (Score:2)
It's just common sense. Why on Earth would you allow keys issued by a 3rd party to remain on your system beyond the setup phase?
Common sense to someone like yourself or myself; however, very few people that I know, including people who are ostensibly professionals, have no idea and therefore, do not care about Secure Boot. They also do not realize that it is a long term trap when the ability create and sign your own keys will be taken from you. Palladium for the win!
What is secure boot? (Score:2, Insightful)
What is secure boot? Why should I care?
Re: (Score:2)
Re: (Score:2)
Not quite. If "attacker" is the owner of the computer, secure boot may enable better Digital Restriction Management (DRM).
Re: (Score:2)
Not really. It does not secure you. If it causes issues, just disable it.
Re: (Score:2)
Re: (Score:2)
Secure boot is a system whereby only "trusted" code can run on your computer. While the idea is good, the implementation leaves a lot to be desired. They are one step away from taking away your ability to sign your own bootloaders, at which point, Linux will not be able to be ran on your "commodity" hardware.
In other words, the idea is sound, but the implementation is designed to take control away from you.
No problem here (Score:3)
I disable Secure Boot on all my devices. Compromised security keys have no impact.
Re: (Score:2)
Yep, same here. It serves no purpose except to make my own system administration harder.
Good (Score:5, Insightful)
Re: (Score:2)
Indeed. No idea why some people still believe secure boot wasd there to protect them.
Re: (Score:3)
Re: (Score:2)
simply blowing Opal-esq write fuses
Nintendo [3dbrew.org] would like a word with you on that.
Obviously (Score:1)
Secure boot is not there to secure your computer. It is there to enable DRM. If DRM does not work on all computers, no problem.
Oh, you thought you were somehow protected by it? Seriously?
Re: (Score:2)
Re: (Score:2)
That too. Agreed.
Not "completely broken" (Score:3)
PASS (Score:2)
protected by a four-character password
Is the password public knowledge? At least tell me it was something silly like "b00b" or "omfg" or "PASS".
Phew! (Score:2)
I turn it off. (Score:2)
I switch SB off on everything I own.
As I mostly run Linux it is not needed and mostly gets in the way when I'm chaging boot methods etc.
At work I'm the opposite, I ensure it is fully enabled etc on our work machines, even though it is trivial to switch off when you have physical access.
I once did look into making my own keys but then I was like "why bother". It is much better to improve your browsing and usage habbits, I have a separate machine that I use for banking for example, it does nothing else but t
One key to rule them all. (Score:1)