Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

arstechnica.com

Post reply on HN
Print view View original

61–70 of 147 posts

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

#61

Post by commercialnix »

Hizonner wrote: post #20
Terr_ wrote: post #11

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…

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.

Not any less reasonable than expecting a mechanic to be competent and knowledgeable with brakes.

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

#62

Post by StillBored »

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

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

#63

Post by commercialnix »

jauntywundrkind wrote: post #5

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…

It's like buying a house with locks that can not be changed.

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

#64

Post by Hizonner »

commercialnix wrote: post #61
Hizonner wrote: post #20

Earlier quoted context omitted.

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.

Not any less reasonable than expecting a mechanic to be competent and knowledgeable with brakes.

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

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

#65

Post by hollerith »

sillywalk wrote: post #52
jauntywundrkind wrote: post #5

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…

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.

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

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

#66

Post by A4ET8a8uTh0 »

out-of-ideas wrote: post #43
acdha wrote: post #22

Earlier quoted context omitted.

Also things around physical access: if you steal my laptop, FDE prevents you from getting my data immediately but if you install malware which takes over the boot process, you get that data as soon as I type in my password. If the process changes so the hardware only loads signed firmware, which only loads a signed boot loader, which only loads a signed kernel, etc. that avenue of attack is closed. It also makes it p…

do folks in the business really simply steal a laptop and try to pull all data? or do they steal the laptop and wipe it and flip it... if they wanted your data wouldnt they steal you, the human, too ? the signing method only offers buying more time before the innevitable data is "breached" by a theat actor - its the same buying-time for any and all encryption. the system can get too complex, and the underlying proble…

As chilling as it may be to explore this line of thought, I think there are real, pragmatic considerations that make 'stealing' humans along with laptops less than ideal. Laptops get damaged, lost and so on all the time. Missing laptop raises some, but minimal suspicion and attention. Now, with a human missing, whoever did the deed, will likely have a difficult time moving around assuming LEOs in the area are competent.

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

#67

Post by Scoundreller »

leeter wrote: post #55
jandrese wrote: post #18

Earlier quoted context omitted.

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.

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 fa…

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

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.

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

#68

Post by tedunangst »

jmclnx wrote: post #56
tedunangst wrote: post #26

Earlier quoted context omitted.

It's only a F12, tab, enter, down, tab, enter away to disable if you really don't like it that much.

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.

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.

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

#69

Post by dathinab »

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.

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

#70

Post by Hizonner »

rurban wrote: post #49

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.

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.

Post reply on HN