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

111–120 of 147 posts

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

#111

Post by antifa »

awaythrow999 wrote: post #109
drhagen wrote: post #6

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

Immediately gets slapped over the head by the requirement: "preventing downgrade to a vulnerable version" (which would be just a matter of enough time passing)

And by "vulnerable version" they mean the version before they added ads to the boot screen.

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

#112

Post by asveikau »

NekkoDroid wrote: post #107
asveikau wrote: post #105

Earlier quoted context omitted.

> could mean in any one of the thousands of departments not even remotely related to Windows. That's true. I was a dev in Windows though. I wasn't privy to any memorable internal discussions about secure boot. Anyway, I'm just saying I'm not a kneejerk windows or ms hater, which I think I read as in discussions like this.

I also am not a blind MS hater or supporter. I probably do often give MS too much leeway for a lot of things where more skeptical people would basically instantly dismiss it. I guess I just try to make the best out of what is given me. > I wasn't privy to any memorable internal discussions about secure boot. I think it was a leaked email from Bill Gates around when UEFI or Secure Boot was becoming a thing. I wasn't a…

Back in the day the euphemism was "trustworthy computing". That may be a good thing to Google to find those emails. I remember then too. Another name was "palladium"

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

#113

Post by plasticchris »

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.

Exactly why I do my own brakes.

And why I want to control my own keys.

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

#114

Post by RiverCrochet »

zzo38computer wrote: post #75
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…

I think that this is part of the way to do it, but not all of it. I might consider: 0. All of the BIOS code and other hardware code should be FOSS. This should be printed in the manual as well. A simple assembly language might be preferable, and if the hex codes are also printed next to it, they can also be entered manually if necessary. 1. The operating system cannot update the BIOS at all. To do so requires to set…

0. Most of the UEFI is already open source. See TianoCore.

1. There are some things that may need to be updated from time to time that need to be applied before the OS is loaded - microcode updates being one of these. I would still like a physical write-enable switch.

2. Making a keyboard that is not a real keyboard is easier than ever with things like Arduino and Raspberry Pi, and it doesn't matter the interface. There is probably not a way to verify physical presence that can't be duplicated remotely. At some point humanity has to get beyond the primitive mentality of "this stuff on a computer monitor/from a speaker looks/sounds just like real stuff so it is the real stuff" and we have to accept that computers are machines and not in and of themselves a proxy for reality unless specifically considered so.

3. Funny, the original 1981 PC booted to ROM BASIC if it couldn't boot off of anything, so it was useful without an OS. I really wish UEFI firmware was on a replaceable SD card and the system would literally have no firmware if it was not present. I would pay the 2 cents more it would cost OEMs. With all the capability in modern chipsets I feel like this would be trivial to do.

4. Good idea. I wish computers had a separate display that is attached through some legacy interface like RS-232 and that doesn't go through VGA at all for this purpose, like a cheap LCD screen.

5. The old punched cards were very low density, but had one really nice property: you could physically see the data with nothing more than your eyes. It's funny that a stack of punched cards could potentially be more secure than millions of instructions of code hidden in a NAND or ROM that you cannot see or verify except with another device that you also have to trust and run on a platform you trust. Even then you can't really see the bits on a NAND or ROM without special expensive equipment. It'd be cool if there could be a high-density storage device where the binary contents are somehow physically viewable and discernable without a CPU needed. Something like QR codes but much, much more high density.

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

#116

Post by yencabulator »

PennRobotics wrote: post #106

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

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.

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

#117

Post by renonce »

snailmailman wrote: post #45

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

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?

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

#118

Post by rurban »

Hizonner wrote: post #70
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 b…

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.

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

#119

Post by zzo38computer »

RiverCrochet wrote: post #114
zzo38computer wrote: post #75

Earlier quoted context omitted.

I think that this is part of the way to do it, but not all of it. I might consider: 0. All of the BIOS code and other hardware code should be FOSS. This should be printed in the manual as well. A simple assembly language might be preferable, and if the hex codes are also printed next to it, they can also be entered manually if necessary. 1. The operating system cannot update the BIOS at all. To do so requires to set…

0. Most of the UEFI is already open source. See TianoCore. 1. There are some things that may need to be updated from time to time that need to be applied before the OS is loaded - microcode updates being one of these. I would still like a physical write-enable switch. 2. Making a keyboard that is not a real keyboard is easier than ever with things like Arduino and Raspberry Pi, and it doesn't matter the interface. Th…

1. Yes. However, disallowing the operating system from automatically starting does not mean that the operating system cannot be started at all. If you deliberately want the operating system to add microcode updates like that, then you can perhaps type "AUTOBOOT" (or whatever the appropriate command is) at the Forth prompt that comes up when the write-enable switch is activated (or, if you don't like that, you can instead write the code to read the microcode updates from a disk, verify their cryptographic hash, and then apply them). FOSS microcode updates would also help with the security issues when doing so.

2. This is true, and can be useful in some circumstances, but having a dedicated port is still more secure, since it means that it will only act as a keyboard if you expect it to do so. (This does not prevent the external device from providing undesired input if it is connected to the keyboard port, but it does prevent it from doing so if it is connected to a different port.)

3. I know that the original 1981 PC has ROM BASIC, and I think that newer computers ought to be designed to do such a thing too (although you could use Forth instead of BASIC if you prefer).

4. I meant an internal connection, not related to any of the existing ones; leaving the RS-232 free for connecting external devices that will use RS-232.

Post reply on HN