19 ms·

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

177 points by verifex 2y ago

deleted 2y ago
[deleted]
rebolek 2y ago
It's a bit of surprise that most of the things work most of the time, given on how shaky basis are they build.
- sadhorse 2y ago
  If you dig deep enough all our land is on a floating basis.
jmclnx 2y ago
>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.
- hex4def6 2y ago
  This has been my theory since Windows 11 required TPM. It's not to protect the consumer, it's to protect the IP-holder. The PC is the lone outlier in the locked-down, walled-garden world of consoles, cell phones, tablets, smart TVs, EVs, etc. I think there's a concerted effort to change that.
  - stonogo 2y ago
    Indeed, I share this outlook, as do others: https://boingboing.net/2012/01/10/lockdown.html https://boingboing.net/2012/01/10/lockdown.html
    - kps 2y ago
      Better late than never. “The actual user of the PC — someone who can do anything they want — is the enemy.” (Intel, 1999)¹ ¹ https://www.zdnet.com/article/the-biggest-security-threat-you/ https://www.zdnet.com/article/the-biggest-security-threat-yo...
  - jandrese 2y ago
    Absolutely. Look at all of the changes to the media stack Microsoft made for Vista and none of them are to directly benefit the person who bought the OS license. If you have ever wondered how a 486 could play MP3s and still run X but your modern laptop gets hot and spins the fan when you are playing those same MP3s it is because the media companies demanded it.
    - tedunangst 2y ago
      If they're literally the same MP3s, it's because modern software sucks. You can still play them with mpg123 with an immeasurably low cpu load.
    - leeter 2y ago
      The pedant in me wants to point out that most 486s couldn't play MP3s (they just don't have the horsepower, an AM-586 or a DX4 maybe) and you'd need a Pentium. /pedant OK now to my real point. Vista is actually a really good call out of MS being inconsistent about this. The major changes in Vista (Moving graphics drivers largely out of the kernel, simplifying what sound drivers could do) were all predicated on the fact that hardware vendors are notoriously bad at software. This cannot be understated just how bad they are, NTKernel was originally intended such that vendors would make their own HAL.. one tried and it was so bad MS just NOPE.jpg'd that and did it themselves. So for MS to double down on a system that relies on the same known to be horrible at software vendors is just hilarious to me.
      - Scoundreller 2y ago
        A 486 DX4-100 could play mp3s in stereo (or in mono at 66mhz), but do absolutely nothing else at the same time. I used a DOS mp3 player (mpxplay) and it could be done. Docs suggest stereo is possible at DX2-80mhz if you disabled screen output and heavy mp3 file pre-buffering. Top level comment here claims the issue was the on-screen animations and they were able to build a highly optimized mp3 player on a 286 (dunno through what speaker): https://m.youtube.com/watch?v=b0zZpzxHSeM https://m.youtube.com/watch?v=b0zZpzxHSeM Even on a later pentium, I had to minimize throttle priority on my web browser because smooth scrolling requires a ton of juice. Still does to this day looking at power consumption on an iPhone.
  - out-of-ideas 2y ago
    fear and planned obsolescence; "all these old things are bad... never mind it's only a day old. throw it away already, and buy the new one. no discounts!"
- tedunangst 2y ago
  It's only a F12, tab, enter, down, tab, enter away to disable if you really don't like it that much.
  - jmclnx 2y ago
    Yes right now, what about 5 to 10 years from now ? Or maybe for that option in the future, the device will cost thousands of USD more. Or you need a special professional license to get a non-locked down device, and the license will cost more than a house in a rich suburb.
    - tedunangst 2y ago
      People have been asking "what about five years from now" for twenty years, so extrapolating from the current rate of change, I'd say things will be fine.
  - josephcsible 2y ago
    You can disable Secure Boot on x86 PCs, but nowhere else.
    - tedunangst 2y ago
      So how do people install openbsd on the thinkpad x13s?
      - josephcsible 2y ago
        Here's an article about the rule being made in the first place (IIRC, the rule got made at the same time Windows on ARM was itself first given to manufacturers): https://softwarefreedom.org/blog/2012/jan/12/microsoft-confirms-UEFI-fears-locks-down-ARM/ https://softwarefreedom.org/blog/2012/jan/12/microsoft-confi... I'm not sure how it's working on those laptops, but I'd imagine the choices are either that Lenovo got given an exception, the rule as a whole got changed, or that Microsoft just hasn't noticed or is intentionally looking the other way.
- deleted 2y ago
  [deleted]
- NekkoDroid 2y ago
  Secure Boot itself is fine, the problem is shipping ANY keys by default. I use Secure Boot myself with my own signed keys on my laptop and its nice knowning it can only run what I allow it to run (password protected UEFI ensures only EFI binaries or kernels I signed get booted and that ensure it mounts my encrypted partitions). The problem is when these other keys are pre-shipped they invalidate the entire "ensures only [...] kernels I signed" part. And just removing the pre-shipped keys can cause other problems: https://github.com/Foxboron/sbctl/wiki/FAQ#option-rom https://github.com/Foxboron/sbctl/wiki/FAQ#option-rom
jauntywundrkind 2y ago
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.)
- sillywalk 2y ago
  As I understand it, that's both the whole point of, and limitation to, the hardware root of trust - it can't be changed even with a firmware update. Of course, if the key used to sign the firmware is compromised, the root of trust is still technically what it is supposed to do - verifying signatures, it's just that that it becomes irrelevant in terms of security / integrity.
  - hollerith 2y ago
    >As I understand it, that's both the whole point of, and limitation to, the hardware root of trust - it can't be changed even with a firmware update. The OP states that the vendors could have revoked the compromised platform key with a firmware update. They just didn't bother.
    - jauntywundrkind 2y ago
      They'd also need to know every user has upgraded the boot loader such that the system doesn't depend on those compromised keys! That does make it quite difficult to pull off any kind of key rotation. I'm not sure, but I think (well known Secure Boot tool) sbctl is saying that you can sign a bootloader with multiple keys, which would permit creating a bootloader that would work with the compromised & the new root-of-trust, which at least opens some window of possibility. https://github.com/Foxboron/sbctl/blob/master/docs/sbctl.8.txt#L109 https://github.com/Foxboron/sbctl/blob/master/docs/sbctl.8.t...
drhagen 2y ago
> 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).
- Terr_ 2y ago
  I'm having strange nostalgic flashbacks the '90s where I kept wondering why nobody offered a hard drive with a physical read-only toggle button. (Mounted to the front of the 5.25 inch bay in a tower chassis, as was the style of the time.) Obviously you need some read+write storage elsewhere on the same computer, but you could reliably freeze large chunks of stuff in a way that would be impervious to viruses or hackers.
  - drhagen 2y ago
    I remember USB drives in the '00s that had a read-only toggle. They were useful for rescuing machines that had a virus. Edit: A quick search reveals that, of course, you can still buy them today. I have not felt a need for one in ages.
    - Terr_ 2y ago
      Hmmm, I would absolutely buy one of those if it also had a hardened case and a firm connection point for my real-world keychain. The use-case is a "my house burned down what next" backup, password-manager stuff and other details I might need before/without accessing any cloud-backup services. I may need to read some of its files on a not-very trusted device, and I don't want to risk that device also tampering/trojan'ing other files, like backup copies of the software needed to decrypt the data files. A simpler scenario might be a USB stick that I use for carrying files to be printed at the local library.
jokoon 2y ago
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?
- bitwize 2y ago
  Secure Boot protects against booting a kernel image that's been tampered with. If the running kernel is vulnerable to root-level exploits, it can't help you, but it can prevent a malicious attacker from switching a trusted kernel for a malicious, modified copy.
  - asveikau 2y ago
    > it can prevent ... switching a trusted kernel for a malicious, modified copy. Or a free OS.
    - NekkoDroid 2y ago
      Being able to enroll your own keys (or disable secure boot entirely) is a requirement for being a compliant implementation. So sign your own kernel with your own keys and enroll them to your UEFI and you have 0 problem with installing "a free OS" (it can also just be regular EFI binaries).
      - 1oooqooq 2y ago
        not to mention be safer than everyone using Intel or Microsoft free for all keys.
      - asveikau 2y ago
        Making a non-microsoft product require manual key enrollment, while Microsoft products do not require such enrollment, sounds like abusing monopoly status to give new entrants a disadvantage. The 1990s antitrust people would have a field day with that one. Also, by the way, I am an ex Microsoft employee, bet you wouldn't guess that from these comments. I do personally consider secure boot and TPM to have been pushed in bad faith, not for serious security concerns.
Terr_ 2y ago
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.
- Hizonner 2y ago
  Platform keys can be replaced given physical access to the computer. In fact they can generally be replaced by regular UEFI updates. The problem here is in trusting, nay expecting, your average motherboard maker to either know anything about key management or give a shit about key management.
  - commercialnix 2y ago
    Not any less reasonable than expecting a mechanic to be competent and knowledgeable with brakes.
    - Hizonner 2y ago
      ... except that in my experience most mechanics are competent with brakes, and most motherboard makers are not competent with cryptography, or indeed with anything having to do with software. The auto repair industry has certain standards, and the computer industry... doesn't. In fact, the computer industry does everything it can to insulate itself from any kind of responsibility.
jandrese 2y ago
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.
- londons_explore 2y ago
  Because nobody ever looked at the text of the certificate. It was probably a binary file checked into the source control system and, since it seemed to work, nobody ever looked at it. Probably came as part of the dev kit from AMI.
  - kevin_thibedeau 2y ago
    The only winning move is not to play. AMI should never have distributed test certs to begin with. Give your customers instructions on how to generate self-signed certificates (assuming they are accepted) or setup a dev CA that will sign test certificates. Then the damage from a key leak is limited to one vendor.
tedunangst 2y ago
"It's EOL so no fix" is pretty shitty. It was defective for its entire unsupported life as well.
nightowl_games 2y ago
Seems apparent we need a Professional Engineering Certification process and our own disciplinary board similar to other engineering disciplines. High time.
- Hizonner 2y ago
  You could probably get away with just forbidding software license agreements that disclaim liability for any and every kind of negligent stupidity.
  - robocat 2y ago
    So forbid the GPL and BSD licenses?
- robocat 2y ago
  To make that work in the US: 1: would need to onshore all work in the bootchain (software and hardware). 2: would put liability on inidividual engineers and take liabilty away from the corporate organisiation. 3: accountability requires that engineers have authority. 4: in a team environment accountability is going to be blamed on the weakest members 5: it would completely fuck any inidividual open source development. If you want to come up with better ideas for accountability, then read up on the witchhunts that occur after deadly failures in other engineering disciplines, and check that your idea fixes the problems you see. The world is far more interconnected now than when my grandad was a certified engineer.
manofmanysmiles 2y ago
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_final.pdf https://uefi.org/sites/default/files/resources/UEFI_Spec_2_8...> - <https://www.apple.com/business/docs/site/Security_Overview.pdf 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.
- StillBored 2y ago
_trampeltier 2y ago
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-android-document-april-2024 https://www.documentcloud.org/documents/24833831-cellebrite-...
- Hizonner 2y ago
  Android 7 is when Google switched from dead simple full-"disk" encryption to per-file hackery with complicated key management. Basically the whole data encryption scheme changed.
snailmailman 2y ago
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.
- renonce 2y ago
  I feel many security researchers like to overemphasize the importance of certain security practices (the most common one being "longer and random password with symbols and upper case letters") without considering its costs, trouble, and human's lazy nature. Forcing long passwords causes people to use repetitive or easy to remember words, enforcing Secure Boot doesn't work if it gets in the way of normal boots. Making sure that these security mechanisms "just work" is as important as enforcing rules like these. A natural question is whether Secure Boot is the right place to protect against the type of attack mentioned in the post. Given that we've already invested a lot of effort in fixing kernel privilege escalations, and any program able to install BIOS rootkits can access all data and modify any program anyway, what justifies the extra complexity of Secure Boot (which includes all the extra design necessary to make it secure, such as OS'es robust to tampering even with kernel privileges)? I mean, why invest so much in Secure Boot when you could harden your kernel to prevent tampering BIOS in the first place?
  - akvadrako 2y ago
    Real security researchers know that requiring symbols and upper case letters actually reduces security. Those requirements are explicitly rejected by the latest NIST recommendations: https://pages.nist.gov/800-63-3/sp800-63b.html https://pages.nist.gov/800-63-3/sp800-63b.html So I'm basically agreeing with you, that a lot of people "in security" are just cargo culting.
rurban 2y ago
Previously in 2023 Intel lost it's private UEFI key on the MSI hack. https://news.ycombinator.com/item?id=35843566 https://news.ycombinator.com/item?id=35843566 This time it's AMI. Cannot get bigger.
- Hizonner 2y ago
  I'm not sure it's reasonable to just treat it as an AMI problem, given that AMI literally named the key "DO NOT TRUST - AMI Test PK". Obviously AMI was stupid to trust the OEMs to, you know, have a clue what they were doing and replace a wired-in test key in their production builds... but it's also true that, even if AMI should have known that the OEMs are idiots, the OEMs are still idiots. I suppose you could also break it down and say that the particular idiot who hardwired a test key in an SDK or whatever should have known that both the rest of AMI and everybody at the OEMs would be idiots, and found a way to make it relatively hard for them to stay with that key. But however far you dig, it's idiots all the way down.
  - rurban 2y ago
    You are right, idiots all the way down. AMI should have created a PK generation script for those idiots. And you need such a script, because everything which can go wrong will go wrong. E.g they'll generate keys with 2044 bits, or such.
StillBored 2y ago
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).
- 1oooqooq 2y ago
  that's out of date for at least 6yrs. most Linux distro already support many ways to generate your own keys and automatically sign your kernels and modules. and bioses have ways to enter "user mode" so you can upload your PK etc. but still, since the attack for this to be worth is out of this world rare... very few orgs bother to even document it in the main guides because it gives zero protection and infinite support load
  - StillBored 2y ago
    I don't think you are understanding my point. The distro installer should, if it detects setup mode, automatically be asking the user if they wish to replace the all the existing keys and enroll distro supplied certs, keys and dbx entries. Except none of the distros have this infrastructure built, outside of their dependence on Microsoft. And no, none of this is needed if all you want is to be able to self sign a kernel/etc because its possible to install a MOK key to shim, but that isn't the point, the point is that the vast majority of linux users aren't setup to protect a cert/key chain from an attacker. Which is the entire reason for secure boot. If your attacker is sophisticated enough they will be stealing the signing keys from your machine/org and signing their own updates. Which is why MOK and self signing is a mistake for ~100% of Linux users.
dathinab 2y ago
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.
PennRobotics 2y ago
> ... key players in security—among them Microsoft and the US National Security Agency ... This phrase does not sit well with me.
- yencabulator 2y ago
  Key player doesn't imply a positive contribution.. A lot of national, corporate, and private security hinges on Microsoft. Also, people have played with Microsoft's keys, for sure.
- scraptor 2y ago
  The largest provider of security holes and the largest user of them.
- okanat 2y ago
  NSA doesn't want the government and critical businesses to get hacked, unless they are doing it themselves. That's why they support many security features in both proprietary and open source world. However, in the US, they don't need to hack; they can just ask for data lawfully.
deleted 2y ago
[deleted]
EVa5I7bHFq9mnYK 2y ago
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.
- senectus1 2y ago
  in a powershell um.. shell: [System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI PK).bytes) -match "DO NOT TRUST|DO NOT SHIP"
  - EVa5I7bHFq9mnYK 2y ago
    tried that, it gives me cryptic errors and gpt is of no help.
tithe 2y ago
Binarly's research report here: https://web.archive.org/web/20240726085758if_/https://22222483.fs1.hubspotusercontent-na1.net/hubfs/22222483/Reports/PKfail%20-%20Binarly%20Research%20Report%20July%2025%202024.pdf https://web.archive.org/web/20240726085758if_/https://222224...
renegat0x0 2y ago
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).

177 points by verifex 2y ago

deleted 2y ago

[deleted]

rebolek 2y ago

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

sadhorse 2y ago
If you dig deep enough all our land is on a floating basis.

jmclnx 2y ago

>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.

hex4def6 2y ago
This has been my theory since Windows 11 required TPM. It's not to protect the consumer, it's to protect the IP-holder. The PC is the lone outlier in the locked-down, walled-garden world of consoles, cell phones, tablets, smart TVs, EVs, etc. I think there's a concerted effort to change that.
- stonogo 2y ago
  Indeed, I share this outlook, as do others: https://boingboing.net/2012/01/10/lockdown.html https://boingboing.net/2012/01/10/lockdown.html
  - kps 2y ago
    Better late than never. “The actual user of the PC — someone who can do anything they want — is the enemy.” (Intel, 1999)¹ ¹ https://www.zdnet.com/article/the-biggest-security-threat-you/ https://www.zdnet.com/article/the-biggest-security-threat-yo...
- jandrese 2y ago
  Absolutely. Look at all of the changes to the media stack Microsoft made for Vista and none of them are to directly benefit the person who bought the OS license. If you have ever wondered how a 486 could play MP3s and still run X but your modern laptop gets hot and spins the fan when you are playing those same MP3s it is because the media companies demanded it.
  - tedunangst 2y ago
    If they're literally the same MP3s, it's because modern software sucks. You can still play them with mpg123 with an immeasurably low cpu load.
  - leeter 2y ago
    The pedant in me wants to point out that most 486s couldn't play MP3s (they just don't have the horsepower, an AM-586 or a DX4 maybe) and you'd need a Pentium. /pedant OK now to my real point. Vista is actually a really good call out of MS being inconsistent about this. The major changes in Vista (Moving graphics drivers largely out of the kernel, simplifying what sound drivers could do) were all predicated on the fact that hardware vendors are notoriously bad at software. This cannot be understated just how bad they are, NTKernel was originally intended such that vendors would make their own HAL.. one tried and it was so bad MS just NOPE.jpg'd that and did it themselves. So for MS to double down on a system that relies on the same known to be horrible at software vendors is just hilarious to me.
    - Scoundreller 2y ago
      A 486 DX4-100 could play mp3s in stereo (or in mono at 66mhz), but do absolutely nothing else at the same time. I used a DOS mp3 player (mpxplay) and it could be done. Docs suggest stereo is possible at DX2-80mhz if you disabled screen output and heavy mp3 file pre-buffering. Top level comment here claims the issue was the on-screen animations and they were able to build a highly optimized mp3 player on a 286 (dunno through what speaker): https://m.youtube.com/watch?v=b0zZpzxHSeM https://m.youtube.com/watch?v=b0zZpzxHSeM Even on a later pentium, I had to minimize throttle priority on my web browser because smooth scrolling requires a ton of juice. Still does to this day looking at power consumption on an iPhone.
- out-of-ideas 2y ago
  fear and planned obsolescence; "all these old things are bad... never mind it's only a day old. throw it away already, and buy the new one. no discounts!"
tedunangst 2y ago
It's only a F12, tab, enter, down, tab, enter away to disable if you really don't like it that much.
- jmclnx 2y ago
  Yes right now, what about 5 to 10 years from now ? Or maybe for that option in the future, the device will cost thousands of USD more. Or you need a special professional license to get a non-locked down device, and the license will cost more than a house in a rich suburb.
  - tedunangst 2y ago
    People have been asking "what about five years from now" for twenty years, so extrapolating from the current rate of change, I'd say things will be fine.
- josephcsible 2y ago
  You can disable Secure Boot on x86 PCs, but nowhere else.
  - tedunangst 2y ago
    So how do people install openbsd on the thinkpad x13s?
    - josephcsible 2y ago
      Here's an article about the rule being made in the first place (IIRC, the rule got made at the same time Windows on ARM was itself first given to manufacturers): https://softwarefreedom.org/blog/2012/jan/12/microsoft-confirms-UEFI-fears-locks-down-ARM/ https://softwarefreedom.org/blog/2012/jan/12/microsoft-confi... I'm not sure how it's working on those laptops, but I'd imagine the choices are either that Lenovo got given an exception, the rule as a whole got changed, or that Microsoft just hasn't noticed or is intentionally looking the other way.
deleted 2y ago
[deleted]
NekkoDroid 2y ago
Secure Boot itself is fine, the problem is shipping ANY keys by default. I use Secure Boot myself with my own signed keys on my laptop and its nice knowning it can only run what I allow it to run (password protected UEFI ensures only EFI binaries or kernels I signed get booted and that ensure it mounts my encrypted partitions). The problem is when these other keys are pre-shipped they invalidate the entire "ensures only [...] kernels I signed" part. And just removing the pre-shipped keys can cause other problems: https://github.com/Foxboron/sbctl/wiki/FAQ#option-rom https://github.com/Foxboron/sbctl/wiki/FAQ#option-rom

jauntywundrkind 2y ago

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.)

sillywalk 2y ago
As I understand it, that's both the whole point of, and limitation to, the hardware root of trust - it can't be changed even with a firmware update. Of course, if the key used to sign the firmware is compromised, the root of trust is still technically what it is supposed to do - verifying signatures, it's just that that it becomes irrelevant in terms of security / integrity.
- hollerith 2y ago
  >As I understand it, that's both the whole point of, and limitation to, the hardware root of trust - it can't be changed even with a firmware update. The OP states that the vendors could have revoked the compromised platform key with a firmware update. They just didn't bother.
  - jauntywundrkind 2y ago
    They'd also need to know every user has upgraded the boot loader such that the system doesn't depend on those compromised keys! That does make it quite difficult to pull off any kind of key rotation. I'm not sure, but I think (well known Secure Boot tool) sbctl is saying that you can sign a bootloader with multiple keys, which would permit creating a bootloader that would work with the compromised & the new root-of-trust, which at least opens some window of possibility. https://github.com/Foxboron/sbctl/blob/master/docs/sbctl.8.txt#L109 https://github.com/Foxboron/sbctl/blob/master/docs/sbctl.8.t...

drhagen 2y ago

> 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).

Terr_ 2y ago
I'm having strange nostalgic flashbacks the '90s where I kept wondering why nobody offered a hard drive with a physical read-only toggle button. (Mounted to the front of the 5.25 inch bay in a tower chassis, as was the style of the time.) Obviously you need some read+write storage elsewhere on the same computer, but you could reliably freeze large chunks of stuff in a way that would be impervious to viruses or hackers.
- drhagen 2y ago
  I remember USB drives in the '00s that had a read-only toggle. They were useful for rescuing machines that had a virus. Edit: A quick search reveals that, of course, you can still buy them today. I have not felt a need for one in ages.
  - Terr_ 2y ago
    Hmmm, I would absolutely buy one of those if it also had a hardened case and a firm connection point for my real-world keychain. The use-case is a "my house burned down what next" backup, password-manager stuff and other details I might need before/without accessing any cloud-backup services. I may need to read some of its files on a not-very trusted device, and I don't want to risk that device also tampering/trojan'ing other files, like backup copies of the software needed to decrypt the data files. A simpler scenario might be a USB stick that I use for carrying files to be printed at the local library.

jokoon 2y ago

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?

bitwize 2y ago
Secure Boot protects against booting a kernel image that's been tampered with. If the running kernel is vulnerable to root-level exploits, it can't help you, but it can prevent a malicious attacker from switching a trusted kernel for a malicious, modified copy.
- asveikau 2y ago
  > it can prevent ... switching a trusted kernel for a malicious, modified copy. Or a free OS.
  - NekkoDroid 2y ago
    Being able to enroll your own keys (or disable secure boot entirely) is a requirement for being a compliant implementation. So sign your own kernel with your own keys and enroll them to your UEFI and you have 0 problem with installing "a free OS" (it can also just be regular EFI binaries).
    - 1oooqooq 2y ago
      not to mention be safer than everyone using Intel or Microsoft free for all keys.
    - asveikau 2y ago
      Making a non-microsoft product require manual key enrollment, while Microsoft products do not require such enrollment, sounds like abusing monopoly status to give new entrants a disadvantage. The 1990s antitrust people would have a field day with that one. Also, by the way, I am an ex Microsoft employee, bet you wouldn't guess that from these comments. I do personally consider secure boot and TPM to have been pushed in bad faith, not for serious security concerns.

Terr_ 2y ago

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.

Hizonner 2y ago
Platform keys can be replaced given physical access to the computer. In fact they can generally be replaced by regular UEFI updates. The problem here is in trusting, nay expecting, your average motherboard maker to either know anything about key management or give a shit about key management.
- commercialnix 2y ago
  Not any less reasonable than expecting a mechanic to be competent and knowledgeable with brakes.
  - Hizonner 2y ago
    ... except that in my experience most mechanics are competent with brakes, and most motherboard makers are not competent with cryptography, or indeed with anything having to do with software. The auto repair industry has certain standards, and the computer industry... doesn't. In fact, the computer industry does everything it can to insulate itself from any kind of responsibility.

jandrese 2y ago

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.

londons_explore 2y ago
Because nobody ever looked at the text of the certificate. It was probably a binary file checked into the source control system and, since it seemed to work, nobody ever looked at it. Probably came as part of the dev kit from AMI.
- kevin_thibedeau 2y ago
  The only winning move is not to play. AMI should never have distributed test certs to begin with. Give your customers instructions on how to generate self-signed certificates (assuming they are accepted) or setup a dev CA that will sign test certificates. Then the damage from a key leak is limited to one vendor.

tedunangst 2y ago

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

nightowl_games 2y ago

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

Hizonner 2y ago
You could probably get away with just forbidding software license agreements that disclaim liability for any and every kind of negligent stupidity.
- robocat 2y ago
  So forbid the GPL and BSD licenses?
robocat 2y ago
To make that work in the US: 1: would need to onshore all work in the bootchain (software and hardware). 2: would put liability on inidividual engineers and take liabilty away from the corporate organisiation. 3: accountability requires that engineers have authority. 4: in a team environment accountability is going to be blamed on the weakest members 5: it would completely fuck any inidividual open source development. If you want to come up with better ideas for accountability, then read up on the witchhunts that occur after deadly failures in other engineering disciplines, and check that your idea fixes the problems you see. The world is far more interconnected now than when my grandad was a certified engineer.

manofmanysmiles 2y ago

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_final.pdf https://uefi.org/sites/default/files/resources/UEFI_Spec_2_8...> - <https://www.apple.com/business/docs/site/Security_Overview.pdf 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.

StillBored 2y ago

_trampeltier 2y ago

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-android-document-april-2024 https://www.documentcloud.org/documents/24833831-cellebrite-...

Hizonner 2y ago
Android 7 is when Google switched from dead simple full-"disk" encryption to per-file hackery with complicated key management. Basically the whole data encryption scheme changed.

snailmailman 2y ago

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.

renonce 2y ago
I feel many security researchers like to overemphasize the importance of certain security practices (the most common one being "longer and random password with symbols and upper case letters") without considering its costs, trouble, and human's lazy nature. Forcing long passwords causes people to use repetitive or easy to remember words, enforcing Secure Boot doesn't work if it gets in the way of normal boots. Making sure that these security mechanisms "just work" is as important as enforcing rules like these. A natural question is whether Secure Boot is the right place to protect against the type of attack mentioned in the post. Given that we've already invested a lot of effort in fixing kernel privilege escalations, and any program able to install BIOS rootkits can access all data and modify any program anyway, what justifies the extra complexity of Secure Boot (which includes all the extra design necessary to make it secure, such as OS'es robust to tampering even with kernel privileges)? I mean, why invest so much in Secure Boot when you could harden your kernel to prevent tampering BIOS in the first place?
- akvadrako 2y ago
  Real security researchers know that requiring symbols and upper case letters actually reduces security. Those requirements are explicitly rejected by the latest NIST recommendations: https://pages.nist.gov/800-63-3/sp800-63b.html https://pages.nist.gov/800-63-3/sp800-63b.html So I'm basically agreeing with you, that a lot of people "in security" are just cargo culting.

rurban 2y ago

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

Hizonner 2y ago
I'm not sure it's reasonable to just treat it as an AMI problem, given that AMI literally named the key "DO NOT TRUST - AMI Test PK". Obviously AMI was stupid to trust the OEMs to, you know, have a clue what they were doing and replace a wired-in test key in their production builds... but it's also true that, even if AMI should have known that the OEMs are idiots, the OEMs are still idiots. I suppose you could also break it down and say that the particular idiot who hardwired a test key in an SDK or whatever should have known that both the rest of AMI and everybody at the OEMs would be idiots, and found a way to make it relatively hard for them to stay with that key. But however far you dig, it's idiots all the way down.
- rurban 2y ago
  You are right, idiots all the way down. AMI should have created a PK generation script for those idiots. And you need such a script, because everything which can go wrong will go wrong. E.g they'll generate keys with 2044 bits, or such.

StillBored 2y ago

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).

1oooqooq 2y ago
that's out of date for at least 6yrs. most Linux distro already support many ways to generate your own keys and automatically sign your kernels and modules. and bioses have ways to enter "user mode" so you can upload your PK etc. but still, since the attack for this to be worth is out of this world rare... very few orgs bother to even document it in the main guides because it gives zero protection and infinite support load
- StillBored 2y ago
  I don't think you are understanding my point. The distro installer should, if it detects setup mode, automatically be asking the user if they wish to replace the all the existing keys and enroll distro supplied certs, keys and dbx entries. Except none of the distros have this infrastructure built, outside of their dependence on Microsoft. And no, none of this is needed if all you want is to be able to self sign a kernel/etc because its possible to install a MOK key to shim, but that isn't the point, the point is that the vast majority of linux users aren't setup to protect a cert/key chain from an attacker. Which is the entire reason for secure boot. If your attacker is sophisticated enough they will be stealing the signing keys from your machine/org and signing their own updates. Which is why MOK and self signing is a mistake for ~100% of Linux users.

dathinab 2y ago

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.

PennRobotics 2y ago

> ... key players in security—among them Microsoft and the US National Security Agency ... This phrase does not sit well with me.

yencabulator 2y ago
Key player doesn't imply a positive contribution.. A lot of national, corporate, and private security hinges on Microsoft. Also, people have played with Microsoft's keys, for sure.
scraptor 2y ago
The largest provider of security holes and the largest user of them.
okanat 2y ago
NSA doesn't want the government and critical businesses to get hacked, unless they are doing it themselves. That's why they support many security features in both proprietary and open source world. However, in the US, they don't need to hack; they can just ask for data lawfully.

deleted 2y ago

[deleted]

EVa5I7bHFq9mnYK 2y ago

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.

senectus1 2y ago
in a powershell um.. shell: [System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI PK).bytes) -match "DO NOT TRUST|DO NOT SHIP"
- EVa5I7bHFq9mnYK 2y ago
  tried that, it gives me cryptic errors and gpt is of no help.

tithe 2y ago

Binarly's research report here: https://web.archive.org/web/20240726085758if_/https://22222483.fs1.hubspotusercontent-na1.net/hubfs/22222483/Reports/PKfail%20-%20Binarly%20Research%20Report%20July%2025%202024.pdf https://web.archive.org/web/20240726085758if_/https://222224...

renegat0x0 2y ago

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).