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

Linux and Secure Boot certificate expiration

lwn.net

Post reply on HN
Print view View original

111–120 of 272 posts

Re: Linux and Secure Boot certificate expiration

#111

Post by magicalhippo »

pdimitar wrote: post #46
blkhawk wrote: post #19

Earlier quoted context omitted.

Secure boot belongs to a class of security that while clearly giving a theoretical benefit in practice it falls far short of providing any benefit whatsoever at least to the user of a system. Its introduction was mostly part of a wider (probably partially defunct and failed regarding mobile x86) strategy to lock down the PC so the Microsoft store and purchased apps through it would be more secure from the end-user. S…

What kinds of attacks was Secure Boot designed to mitigate? Is it the evil maid attack? Or an accidentally ran with `sudo` program can indeed screw your entire boot process and inject rootkits etc.? Or is it something else?

> Or an accidentally ran with `sudo` program can indeed screw your entire boot process and inject rootkits etc.?

The more realistic scenario would be exploiting a privilege escalation bug. Of which there have been and will be plenty of on both Windows and Linux.

Re: Linux and Secure Boot certificate expiration

#112

Post by m4rtink »

RedShift1 wrote: post #97
jeroenhd wrote: post #52

Earlier quoted context omitted.

The mistake was not to put an expiry date on the certificates, but to trust hardware vendors to do even basic firmware maintenance after motherboards and laptops leave the warehouse. In theory a KEK update will fix the expiry issue just like a CA package update on any normal operating system will do. In practice, most UEFI firmware is written like trash, unmaintained, and mostly untested.

Which to me leads me to a bigger problem, UEFI is trash, too complicated, too bloated, too hard to implement all the various bits and pieces. In my opinion the system firmware should do the absolute minimum possible. Find a piece of data somewhere that the processor can start executing, like in the BIOS days where it would just load in the first 512 bytes and start running that. Anything else like hardware configurat…

Mobile phones and a lot of embedded systems have minimal system firmware like this and it is a total disaster, basically forcing you to have per device special software releases with all the hardware specific things EFI would abstract for you, enabling a generic system software image supporting many devices.

As a result, many of these devices are buggy, insecure & are never updated once shipped or updates get abandoned soon after.

Re: Linux and Secure Boot certificate expiration

#113

Post by msgodel »

RedShift1 wrote: post #97
jeroenhd wrote: post #52

Earlier quoted context omitted.

The mistake was not to put an expiry date on the certificates, but to trust hardware vendors to do even basic firmware maintenance after motherboards and laptops leave the warehouse. In theory a KEK update will fix the expiry issue just like a CA package update on any normal operating system will do. In practice, most UEFI firmware is written like trash, unmaintained, and mostly untested.

Which to me leads me to a bigger problem, UEFI is trash, too complicated, too bloated, too hard to implement all the various bits and pieces. In my opinion the system firmware should do the absolute minimum possible. Find a piece of data somewhere that the processor can start executing, like in the BIOS days where it would just load in the first 512 bytes and start running that. Anything else like hardware configurat…

You do also need to assist the OS in doing hardware probing. Even older BIOS systems had ACPI and other standards.

Re: Linux and Secure Boot certificate expiration

#114

Post by msgodel »

blkhawk wrote: post #19
nine_k wrote: post #9

Earlier quoted context omitted.

Basically every x64 computer is intended to be able to run Windows. Hence MS had to be involved, and I suppose nobody else with serious money wanted the burden. AFAICT you can still disable Secure Boot in most UEFI firmware, and boot anything you like (or not like, if an attacker tampers with your system).

Secure boot belongs to a class of security that while clearly giving a theoretical benefit in practice it falls far short of providing any benefit whatsoever at least to the user of a system. Its introduction was mostly part of a wider (probably partially defunct and failed regarding mobile x86) strategy to lock down the PC so the Microsoft store and purchased apps through it would be more secure from the end-user. S…

Anything that locks you out of your own computer is at absolute best an availability failure but more often than not forces you to use compromised system software.

Re: Linux and Secure Boot certificate expiration

#115

Post by tempnew »

ACCount36 wrote: post #71
flexagoon wrote: post #66

Earlier quoted context omitted.

> Who controls the fucking certs? Cert authorities, just like in case of SSL. Is SSL also an evil technology designed to take away freedom from the internet? > vendor-selected boot certificates that can't be changed That's a lie. Certain drivers are signed with a specific key, and they can only be used when this key is installed, which makes sense. The same thing happens with SSL - if you remove pre-installed CA cert…

Take an iPhone or a Switch. Then disable Secure Boot on it. Good fucking luck. The reason why Apple or Nintendo go out of their way to make this impossible isn't user security. It's the "security" of their 30% App Store cut. Out in the wild, Secure Boot exists to "secure" vendor revenue streams - and PCs are the only devices where it's even possible for the user to disable it. Most of the time. What's happening in sm…

Freedom vs safety should be contextual. I’m not free if I don’t have choices and secure boot is a choice. Having it improves both my freedom and security somewhat. I want both unlocked and locked hardware, for different purposes.

Re: Linux and Secure Boot certificate expiration

#116

Post by m4rtink »

preisschild wrote: post #110
ACCount36 wrote: post #49

Earlier quoted context omitted.

Who controls the fucking certs? "My computer was compromised with an early boot stage hypervisor backdoor" happens basically never. It's an attack vector that exists almost entirely in the minds of infosec fucktards. "My brand new device ships with vendor-selected boot certificates that can't be changed, can't be overridden, and control what software I can install onto my own device" happens with every other smartpho…

> Who controls the fucking certs? You can? Delete the default (ie Windows certs) and import your own.

I think it is only required on x86 EFI machines due to some old antitrust rulings. Provided the firmware vendor actually implements it right.

On ARM for example the hardware, including some hardware shipping with ARM version of Windows, does not need to provide the option to add custom certs and remove existing ones, so AFAIK in most cases it is not possible.

Re: Linux and Secure Boot certificate expiration

#117

Post by jeroenhd »

numpad0 wrote: post #100
jeroenhd wrote: post #52

Earlier quoted context omitted.

The mistake was not to put an expiry date on the certificates, but to trust hardware vendors to do even basic firmware maintenance after motherboards and laptops leave the warehouse. In theory a KEK update will fix the expiry issue just like a CA package update on any normal operating system will do. In practice, most UEFI firmware is written like trash, unmaintained, and mostly untested.

There is no basic firmware maintenance to do. Firmware is supposed to be properly engineered, immutable, still to this day sometimes physically wired as 1s and 0s. It doesn't make sense to have expiry dates carved in stone.

Firmware needs maintenance because unless you're doing stuff for the aerospace industry, you're not mathematically proving that your firmware is bug-free. Eventually someone will need to install updates.

Well-written firmware doesn't need to be updated for the key database to get updated. However, some vendors messed up and now require firmware updates, while others simply store the new key in NVRAM.

Re: Linux and Secure Boot certificate expiration

#118

Post by jeroenhd »

account42 wrote: post #98
jeroenhd wrote: post #52

Earlier quoted context omitted.

The mistake was not to put an expiry date on the certificates, but to trust hardware vendors to do even basic firmware maintenance after motherboards and laptops leave the warehouse. In theory a KEK update will fix the expiry issue just like a CA package update on any normal operating system will do. In practice, most UEFI firmware is written like trash, unmaintained, and mostly untested.

No, the real mistake was putting the root of trust anywhere else than the user.

The user can load their own keys into their secure boot storage and use those keys without any interference from pre-installed certificate authorities.

This issue only affects the people who don't want to bother being the root of trust.

Re: Linux and Secure Boot certificate expiration

#119

Post by jeroenhd »

mkj wrote: post #108
jeroenhd wrote: post #52

Earlier quoted context omitted.

The mistake was not to put an expiry date on the certificates, but to trust hardware vendors to do even basic firmware maintenance after motherboards and laptops leave the warehouse. In theory a KEK update will fix the expiry issue just like a CA package update on any normal operating system will do. In practice, most UEFI firmware is written like trash, unmaintained, and mostly untested.

What purpose does the expiry date have? There might be something I've missed, but I really can't see one apart from needless complication, which is what makes it a mistake. (There are other problems in the UEFI/firmware ecosystem yes, but that doesn't excuse expiry dates)

I don't know if this is why the people behind secure boot adopted this design, but expiry dates make CRLs smaller, at least in theory. If a revoked certificate expires, you don't need to add it to the CRL because trust is invalidated automatically. By rotating root keys occasionally, you can also keep the revocation list for vulnerable bootloaders smaller, as you can remove any vulnerable bootloader when its signatory key expires.

With the kind of penny-pinching that happens with NVRAM storage on boards like these, being able to reduce the size of CRLs can make a difference.

Re: Linux and Secure Boot certificate expiration

#120

Post by speeder »

zozbot234 wrote: post #78
flexagoon wrote: post #66

Earlier quoted context omitted.

> Who controls the fucking certs? Cert authorities, just like in case of SSL. Is SSL also an evil technology designed to take away freedom from the internet? > vendor-selected boot certificates that can't be changed That's a lie. Certain drivers are signed with a specific key, and they can only be used when this key is installed, which makes sense. The same thing happens with SSL - if you remove pre-installed CA cert…

> Which is exactly why users have the freedom and choice to just disable Secure Boot? There's some x86 hardware in the wild where the option to disable Secure Boot does not work. Which is part of the reason why Shim exists in the first place - it allows you to boot unsigned code with the machine owner's consent, even with Secure Boot enabled.

I had a Windows 8 laptop like this. Not only that, it rejected Shim too. Never managed to install Linux on it.

Weirdly I had to leave secure boot option turned off too after a while, because more and more games started to have issues with the nVidia GPU. There was a RPG I forgot the name, isometricish that would outright crash if secure boot was turned on.

Post reply on HN