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

I’ve had so many issues with secure boot on my machines causing issues that if I ever saw a secure boot error message I would never think “oh I must have a rootkit”

Instead I would assume, in order

- my config broke it

- OS update broke it

- the bios doesn’t properly handle any case that isn’t “preinstalled OEM windows”

I had a laptop that as far as I could tell, could only boot into windows’ default bootmgr.efi. I could turn off secure boot, and tamper with that efi to boot Linux, but it refused to acknowledge other boot loaders from within the bios. It wouldn’t surprise me in the slightest if secure boot isn’t properly handled. I’ve had too many issues with cheap computers having janky bioses.

> To this day, key players in security—among them Microsoft and the US National Security Agency—regard 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.

Am I correct that Secure Boot purely exists to prevent this attack vector: malware gets root on the OS, hardware allows updating firmware via OS now owned by malware, but Secure Boot means you have to wipe only the hard drive instead of the firmware to eliminate the malware.

It seems like it would be a lot simpler and more reliable to add a button to motherboards that resets the firmware to the factory version (on memory that can't be written by a malicious OS).

It sounds like the biggest contributory problems here are:

1. Allowing unattended/automatic BIOS updates from a running OS at all

2. Being so paranoid about attacks by a spy with physical access to the computer that the keys cannot be replaced or revoked

I'm not a security researcher, but to just shoot the breeze a bit, imagine:

1. The OS can only enqueue data for a proposed BIOS update, actually applying it requires probable-human intervention. For example, reboot into the currently-trusted BIOS, and wait for the user to type some random text shown on the screen to confirm. That loop prevents auto-typing by a malicious USB stick pretending to be a keyboard, etc.

2. Allow physical access to change crypto keys etc, but instead focus on making it easy to audit and detect when it has happened. For example, if you are worried Russian agents will intercept a laptop being repaired and deep-rootkit it, press a motherboard button and record a values from a little LED display, values that are guaranteed to change if someone alters the key set and/or puts on a new signed BIOS. If you're worried, they'll simply replace the chipwork itself, then you'd need a way to issue a challenge and see a signed verifiable response.

This big mistake though was back when all this was being enabled on PC's, the linux vendors out of fear that the rest of the industry would lock them out, standardized on shim and the MS certificates in the firmware. Thus requiring MS to sign the first stage of every linux install/boot rather than both doing that, as well as defaulting to an environment where the distros would boot in UEFI 'setup mode' enroll their own cert/key chains during the first provision/boot, and then permanently switch to user mode. Had they done that, this entire article would have been just about meaningless as all those test keys would have been replaced the moment the machine was installed.

So today a decade+ later there still isn't a standard way to automatically enroll a linux distribution's keys during initial install in any of the distributions (AFAIK).

It feels utterly absurd that devices typically have certain keys are baked in, cannot be removed. I believe there are still Microsoft keys on nearly every device?

It's unconscionable to tell users this is here to keep you safe, but that you have no control over it & if something goes wrong well then too bad, at best we might provide an update.

(Also that governments can probably force these root-of-trust companies to sign payloads to circumvent security is also pretty icky to me.)

Previously in 2023 Intel lost it's private UEFI key on the MSI hack. https://news.ycombinator.com/item?id=35843566

This time it's AMI. Cannot get bigger.

UEFI comes with SB, Microsoft introduces TPM, Google introduces WEI. They will will say it is for your benefit, and in part it is correct, but security can be achieved through many measures, and corporations will choose such solutions that will grant them more ability to control your device.

This leads to accumulation of "power", and monopolization of it in systems leads to vulnerability. One point of failure is enough to compromise entire ecosystem.

Just reminds me that apple checked every application you run, for "safety reasons" (rather checks app certificates, but that is nearly the same).

"It's EOL so no fix" is pretty shitty. It was defective for its entire unsupported life as well.

It's a bit of surprise that most of the things work most of the time, given on how shaky basis are they build.

> ... key players in security—among them Microsoft and the US National Security Agency ...

This phrase does not sit well with me.

Isn't that a vulnerability that still requires physical access to hardware?

Or is that just a protection against rootkits?

I still fail to understand what secure boot is protecting against: if a machine is compromised remotely, does secure boot prevents installing a rootkit that's invisible from virus scanners?

Binarly's research report here: https://web.archive.org/web/20240726085758if_/https://222224...

Seems apparent we need a Professional Engineering Certification process and our own disciplinary board similar to other engineering disciplines.

High time.

I know never to trust software written by hardware folks, but seriously, how do you ship a key where the CN is literally "DO NOT TRUST -- AMI Test PK" as the root security. That is outright malicious incompetence.

A bit oftopic but when last week came out, Cellebrite could open the Trump shooters phone, there was a PDF, they can brute force all android phones since from Android 7 or newer. What changed there? Why can they brute force all newer versions?

https://www.documentcloud.org/documents/24833831-cellebrite-...

How do I check if my laptop is affected? Tried

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

, gives me cryptic errors and gpt of no help.

I just wanted to check if I'm affected.

...

then remembered I'm using custom platform keys

tbh. I don't understand why secure boot is build around global root of trusts instead of ad-hoc per device trust (i.e. like custom platform keys but with better support), at most supported by some global PKI to make bootstraping on initial setup easier

this would not eliminate but massively reduce how much "private key" got leaked vulnerabilities can affect secure boot chains (also move most complexity from efi into a user changeable chain loaders, including e.g. net boot, etc.)

PS:

To be clear " I don't understand why" is rhetorical, I do understand why and find it a terrible bad idea.

Unless I'm missing something, Secure Boot as designed is fundamentally broken.

Its root of trust is the BIOS/Firmware, which can be updated from a running OS. There is no hardware root of trust.

How Secure Boot Works

Secure Boot ensures that a device boots using only software trusted by the Original Equipment Manufacturer (OEM). Here's a high-level overview:

1. Power On and Initialization: The CPU initializes and runs the BIOS/UEFI firmware, which prepares the system for booting.

2. Platform Key (PK) Verification: The firmware verifies the Platform Key (PK), which is used to validate Key Exchange Keys (KEKs).

3. Key Exchange Keys (KEK) Verification: The KEKs validate the allowed (whitelist) and disallowed (blacklist) signature databases.

4. Signature Database Verification: The firmware checks the allowed (db) and disallowed (dbx) signature databases for trusted software signatures.

5. Bootloader Verification: The firmware verifies the bootloader’s signature against the db. If trusted, the process continues.

6. Kernel and Driver Verification: The bootloader verifies the OS kernel and critical drivers’ signatures.

7. Operating System Boot: Once all components are verified, the OS loads.

Apple Secure Boot Process

Apple adds hardware-based security with the Secure Enclave:

1. Secure Enclave Initialization: Separate initialization handles cryptographic operations securely.

2. Root of Trust Establishment: Starts with Apple's immutable hardware Root CA.

3. Immutable Boot ROM Verification: The boot ROM verifies the Low-Level Bootloader (LLB).

4. LLB Verification: The LLB verifies iBoot, Apple's bootloader.

5. iBoot Verification: iBoot verifies the kernel and its extensions. The Secure Enclave ensures cryptographic operations remain protected even if the main processor is compromised.

For more details, check out:

- <https://uefi.org/sites/default/files/resources/UEFI_Spec_2_8...>

- <https://www.apple.com/business/docs/site/Security_Overview.p...>

I would really love to have a hardware root of trust on a Linux or other open system, with a hardware security module of sorts that is programmable, so I decide what the root keys are, and is able to measure the firmware boot process, establishing a proper audit trail or chain of trust.

I can't remember the HN formatting rules, so expect an edit shortly to make this look better.

Edit: I did a little more poking. It's not quite as bad as I thought, because at least in theory, the BIOS will verify a digital signature of a BIOS update before flashing it.

>In 2012, an industry-wide coalition of hardware and software makers adopted Secure Boot to protect against a long-looming security threat

This joke never gets stale, wait it is not a joke ?

I still believe the only reason for this to exist is to eventually turn general computing devices into a locked down Cell Phone Spying Device.