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

91–100 of 147 posts

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

#91

Post by NekkoDroid »

jmclnx wrote: post #4

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

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

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

#92

Post by 1oooqooq »

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 support load

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

#93

Post by 1oooqooq »

NekkoDroid wrote: post #88
asveikau wrote: post #19

Earlier quoted context omitted.

> it can prevent ... switching a trusted kernel for a malicious, modified copy. Or a free OS.

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

not to mention be safer than everyone using Intel or Microsoft free for all keys.

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

#94

Post by hollerith »

jauntywundrkind wrote: post #77
hollerith wrote: post #65

Earlier quoted context omitted.

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

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

This consumer (me) values security highly enough that he would prefer for the firmware update to render the machine unbootable (as long as it remains possible to render the machine bootable again by re-installing software).

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

#95

Post by acdha »

from-nibly wrote: post #86
acdha wrote: post #85

Earlier quoted context omitted.

Good point. I was thinking “PC” as opposed to phones but those totally count.

Chromebooks aren't phones.

Yes, hence my agreement with sillywalk. In my original comment I was thinking of the category of PC-like things which are more geared towards work and phones which are more limited.

Phones don’t have as much contrast because there are several vendors approaching Apple’s level of security, whereas on the classic PC side it’s just a mess. ChromeOS is an excellent addition to the comparison since it’s more locked down than a PC but still productive for many workers and really shows that the problem is coordination. Google cares about security and their ChromeOS devices are more secure than most PCs despite having a lot in common because they don’t leave it to the whims of the hardware vendor.

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

#96

Post by Terr_ »

nucleardog wrote: post #73
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…

> Allow physical access to change crypto keys etc, but instead focus on making it easy to audit and detect when it has happened. Shooting the breeze as well... Have some (non-modifiable, non-updatable) portion of the firmware that, on boot, calculates a checksum or hash of the important bits at the beginning of the chain of trust (efi vars, bios). Then have it generate some sort of visualization of the hash (thinking…

I think the weakness comes if someone can predict or infer what the current display is, and then craft a malicious update that generates something visually similar enough to pass unnoticed.

Perhaps the kitten's bow is pink, instead of red, etc. Even a little bit of wiggle room makes the attacker's job a lot easier, much like the difference between creating something that resolves to a known SHA256 hash versus something which matches a majority but not all of the bits.

A simpler approach would be for the small piece of trusted code to discard and replace the hash/representation With a completely new sufficiently-different one whenever anything changes.

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

#97

Post by megous »

acdha wrote: post #22
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…

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…

> It also makes it possible to trust a used computer.

Thankfully all this complexity is not the only thing that allows to trust a used computer. There are other options, like not having a modifiable SW (that is SW not stored in non-replaceable ROM) run prior to handing off control to bootloader loaded from external media.

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

#98

Post by asveikau »

NekkoDroid wrote: post #88
asveikau wrote: post #19

Earlier quoted context omitted.

> it can prevent ... switching a trusted kernel for a malicious, modified copy. Or a free OS.

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

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.

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

#99

Post by bitwize »

NekkoDroid wrote: post #88
asveikau wrote: post #19

Earlier quoted context omitted.

> it can prevent ... switching a trusted kernel for a malicious, modified copy. Or a free OS.

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

> Being able to enroll your own keys (or disable secure boot entirely) is a requirement for being a compliant implementation.

No, it's really not.

Currently Microsoft requires enrolling keys and disabling SB to be available to qualify for "Designed for Windows" branding on x86 PCs. No such requirement holds for ARM PCs, and Microsoft may remove this requirement at any time.

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

#100

Post by m463 »

acdha wrote: post #22
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…

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 enterprise vendors like dell do it well enough to meet corporate requirements?
Post reply on HN