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

141–147 of 147 posts

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

#141

Post by fuzzfactor »

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…

>1. The operating system cannot update the BIOS at all.

This would be so much more advanced than we have now.

Reverting to an approach proven so superior over more decades would not be a step backward by comparison to UEFI.

You really need to once again be able to reflash your motherboard using a clean image and have no possibility of any malware remaining on-board after that if things are going to be as advanced as it once was also.

For decades I thought it was always going to be normal for a quick reflash of the bios to give complete confidence and trusted validation that you could then rapidly rebuild a verifiably clean system from scratch using clean sources every time.

Progress can surely occur without advancement :/

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

#142

Post by commercialnix »

jeroenhd wrote: post #130
plasticchris wrote: post #113

Earlier quoted context omitted.

Exactly why I do my own brakes. And why I want to control my own keys.

Luckily, you can ignore the factory keys and load your own. This issue affects the default configuration, from what I can tell loading in your own PK will override the built-in ones.

I was thinking about this too, thinking about the TPM 2.0 configuration of some machines. However, the keys used by TPM are not the "platform key".

> from what I can tell loading in your own PK will override the built-in ones

How can one go about doing this? If you have any resources that can show how, please share them. The public key of the "platform key" is "fused" into the hardware, is it not?

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

#143

Post by StillBored »

1oooqooq wrote: post #92
StillBored wrote: post #62

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

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

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.

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

#144

Post by StillBored »

jeroenhd wrote: post #132
StillBored wrote: post #62

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

Arch has a pretty useful key enrollment tool that I'm sure exists on other distros too. Only command line, though. There's also tooling for enrolling a custom key database if your firmware doesn't accept the standard API by creating a bootable key management update tool with your preferred keys. There's a guide for both approaches here: https://wiki.archlinux.org/title/Unified_Extensible_Firmware... . You'll need to…

As I pointed out to the other respondent, I don't think people are understanding what i'm saying. I'm not suggesting that its not possible to manually enroll, or self sign (which should come with a giant warning that it basically invalidates much of the security if the signing keys aren't protected with something hopefully more complex than a keyboard entered password).

Basically the installers should be replacing the existing certs and keys, with distro supplied ones which are maintained along with global DBX entries by the distro itself, with a distro supplied KEK/etc where the private keys are stored in a high security environment not available to most users.

Its really the kind of project the linux foundation should be sponsoring so the infra could be shared cross distro.

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

#145

Post by EVa5I7bHFq9mnYK »

senectus1 wrote: post #128
EVa5I7bHFq9mnYK wrote: post #115

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.

in a powershell um.. shell: [System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI PK).bytes) -match "DO NOT TRUST|DO NOT SHIP"

tried that, it gives me cryptic errors and gpt is of no help.

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

#146

Post by renonce »

OccamsMirror wrote: post #131
renonce wrote: post #117

Earlier quoted context omitted.

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…

The idea is to stop you getting rootkits that can never be removed. You want to feel safe knowing you can just wipe your computer and start again.

You can usually flash BIOS while wiping your computer in the same way that a malware does except in very rare cases. Also Secure Boot doesn't remove the kind of rootkit that doesn't get removed along with the storage since it has to boot from your hard drive anyway.

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

#147

Post by 1oooqooq »

StillBored wrote: post #143
1oooqooq wrote: post #92

Earlier quoted context omitted.

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

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

ah yes. good point.

it doesn't help that the team (guy?) doing all the systemd unification for those features now work for Microsoft anyway.

Post reply on HN