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

Another Crack in the Chain of Trust: Uncovering (Yet Another) Secure Boot Bypass

binarly.io

Post reply on HN
Print view View original

91–100 of 142 posts

Re: Another Crack in the Chain of Trust: Uncovering (Yet Another) Secure Boot Bypass

#91

Post by autoexec »

FirmwareBurner wrote: post #79
autoexec wrote: post #69

Earlier quoted context omitted.

Then why force it into consumer hardware? If it were only available on enterprise servers nobody would care.

>Then why force it into consumer hardware? It's not forced. You can disable secure boot and all that in BIOS.

TPM has to be there. If you have a machine that doesn't support a high enough version your OS vendor will refuse to give you any support and if you have secure boot disabled the software you try to run might refuse to work. Today, you can disable secure boot and have a degraded experience, tomorrow, who knows?

If this really were all only for enterprise users things like https://old.reddit.com/r/ValorantTechSupport/comments/1g4rkh... wouldn't be an issue but that isn't reality.

Re: Another Crack in the Chain of Trust: Uncovering (Yet Another) Secure Boot Bypass

#92

Post by privatelypublic »

worthless-trash wrote: post #53
nikanj wrote: post #47

Earlier quoted context omitted.

To be fair, many CVEs are just that

Everyone says that till they get remote rootkitted in ane exploit chain that uses a moderate rated cve.

More like: go see fusee gelee. Nvidia didn't do boundary checking on their usb DFU boot and it compromised every nintendo switch up to that date, and (i expect) got all nvidia shields' level 2 widevine keys revoked.

Re: Another Crack in the Chain of Trust: Uncovering (Yet Another) Secure Boot Bypass

#93

Post by jrm4 »

RiverCrochet wrote: post #82
jrm4 wrote: post #31

I still genuinely struggle to understand the advantage of UEFI/Secureboot whatever over BIOS. I own a piece of hardware, so I can do what I want to it. Out there, there is software, which I have to figure out how I'm going to trust, whether it's e.g Windows and I'm trusting that whole way of doing things, or Linux and that other whole way of doing things.

If an attacker gains root privileges on your system, an attacker can modify the bootloader on your boot device to load a different kernel than the one you have installed, possibly one that the attacker uploaded that may have backdoors, etc. Secure boot requires that the bootloader match a hash derived from a TPM-stored key. Of course, you get the same protection (and update hassle) by storing the bootloader in someth…

"If an attacker gains root privilieges.."

LOLOL lemme stop ya right there chief. I'm screwed anyway? This is ridiculous.

Re: Another Crack in the Chain of Trust: Uncovering (Yet Another) Secure Boot Bypass

#94

Post by AnthonyMouse »

mjg59 wrote: post #63
AnthonyMouse wrote: post #35

Earlier quoted context omitted.

How is it any different? You install the hash of the boot loader when you issue the machine, then use the trusted system to update the hash if necessary. Also, the concern is that the system comes from the factory with private keys the owner doesn't have access to, allowing the device to defect by informing on them to a third party. Keys installed by the owner rather than the manufacturer are fine, and then such keys…

If a device is running code you control, how does it defect?

If you can't make it do something you don't want it to do, someone else can't pressure you to do it.

Re: Another Crack in the Chain of Trust: Uncovering (Yet Another) Secure Boot Bypass

#95

Post by AnthonyMouse »

mschuster91 wrote: post #50
AnthonyMouse wrote: post #35

Earlier quoted context omitted.

How is it any different? You install the hash of the boot loader when you issue the machine, then use the trusted system to update the hash if necessary. Also, the concern is that the system comes from the factory with private keys the owner doesn't have access to, allowing the device to defect by informing on them to a third party. Keys installed by the owner rather than the manufacturer are fine, and then such keys…

> How is it any different? You install the hash of the boot loader when you issue the machine, then use the trusted system to update the hash if necessary. With your private CA you can skip the "update the hash" part, removing a crucial step that one might forget in a hurry or that simply might go wrong because of whatever sort of bug or power outage... and brick thousands of machines as a result.

The "update hash" part is the counterpart to the "sign the binary" part, so if you forget to do it you're going to have problems either way. Also, this is the sort of thing that large organizations would have automated tooling to do anyway.

Re: Another Crack in the Chain of Trust: Uncovering (Yet Another) Secure Boot Bypass

#96

Post by AnthonyMouse »

mjg59 wrote: post #62
AnthonyMouse wrote: post #34

Earlier quoted context omitted.

> What if you need to update the bootloader? Then you boot the system from the existing bootloader, causing the booted system to be trusted to supply a new hash. > TPMs can do remote attestation without signatures just fine, by measuring the hash of the bootloader. If there are no private keys in the TPM from the factory then there is nothing for a third party to force you to sign the hash with, as intended.

How does the system know whether the new bootloader is legitimate or not? All TPMs have private keys from the factory. They're entirely unrelated to the secure boot keys.

> How does the system know whether the new bootloader is legitimate or not?

However it wants to. Maybe the existing bootloader (chosen by the owner rather than the vendor) or the OS it loads has its own signature verification system for update packages, like apt-get. Maybe the OS downloads it from a trusted URL via HTTPS and relies on web PKI. Maybe it uses Kerberos authentication to get it from the organization's own update servers. Maybe it just boots an OS that allows the operator to apply any update they want from a USB stick, but only after authenticating with the OS.

None of that is the firmware's problem, all it has to do is disallow modifications to itself unless the owner has entered the firmware password or the system is booted from the owner-designated trusted bootloader.

> All TPMs have private keys from the factory. They're entirely unrelated to the secure boot keys.

The point isn't which device has the keys, it's that it shouldn't contain any from the factory. Nothing good can come of it.

Re: Another Crack in the Chain of Trust: Uncovering (Yet Another) Secure Boot Bypass

#97

Post by FirmwareBurner »

autoexec wrote: post #91
FirmwareBurner wrote: post #79

Earlier quoted context omitted.

>Then why force it into consumer hardware? It's not forced. You can disable secure boot and all that in BIOS.

TPM has to be there. If you have a machine that doesn't support a high enough version your OS vendor will refuse to give you any support and if you have secure boot disabled the software you try to run might refuse to work. Today, you can disable secure boot and have a degraded experience, tomorrow, who knows? If this really were all only for enterprise users things like https://old.reddit.com/r/ValorantTechSupport/c…

Then buy a machine without TPM. Or buy games that don't require TPM.

Of course online multiplayer games are gonna have more stringent device security requirements to try to deter cheaters on the PC platforms. Companies aren't gonna mass produce new HW and SW customized to your own individual desires just because you want something else than the masses of consumers don't care about.

Vote with your wallet if TPM bothers you. Otherwise I don't see what your argument stands on.

Re: Another Crack in the Chain of Trust: Uncovering (Yet Another) Secure Boot Bypass

#98

Post by bcantrill »

bradfa wrote: post #64
wmf wrote: post #29

Earlier quoted context omitted.

I think you could get AGESA and combine it with EDK2 yourself; it's just person-years of work.

Unfortunately it’s not quite that simple. Yes you can likely get AGESA but there is a whole bunch of other code you’d still have to write yourself and it’s not trivial without quite a few documents that AMD is unlikely to give you even with normal NDAs. Now, Intel platforms you maybe have a shot at using EDK2 on, especially those with FSP. But Intel is unlikely to give you any support when something goes wrong and th…

Yes, that's all (unfortunately) correct. Part of the reason that we have been supportive of the openSIL effort[0] is to make our approach more generally attainable -- and of course we have opened our own work[1] and we will continue to be outspoken advocates for transparency at the hardware/software interface[2].

[0] https://github.com/openSIL/openSIL

[1] https://github.com/oxidecomputer/illumos-gate

[2] https://rfd.shared.oxide.computer/rfd/0552

Re: Another Crack in the Chain of Trust: Uncovering (Yet Another) Secure Boot Bypass

#99

Post by Nextgrid »

jrm4 wrote: post #31

I still genuinely struggle to understand the advantage of UEFI/Secureboot whatever over BIOS. I own a piece of hardware, so I can do what I want to it. Out there, there is software, which I have to figure out how I'm going to trust, whether it's e.g Windows and I'm trusting that whole way of doing things, or Linux and that other whole way of doing things.

"BIOS vs UEFI" and Secure Boot are two different things.

UEFI supports the latter if you want and configure it, but it's not a requirement of UEFI, and technically a BIOS could also implement signature verification of the boot sector.

Re: Another Crack in the Chain of Trust: Uncovering (Yet Another) Secure Boot Bypass

#100

Post by neilv »

miki123211 wrote: post #66
neilv wrote: post #20

Earlier quoted context omitted.

> It’s something about hardware companies writing software. I've seen enough examples of that, to suspect there's some truth to it, and wonder why that is... Speculation: * Systems programming is hard, and systems programmers who are familiar enough with the kind of target hardware are even more rare. A company might decide to hire a hardware engineer who can code, rather than a systems programmer software engineer w…

It's not a point of competition, plain and simple. Better software doesn't sell more hardware. From those companies' point of view, what matters is hardware features to make consumers want the product, and manufacturing efficiency to make margins high. The quality of what's in the ROM is no more important than the quality of the fans, servos, DACs or what have you. As long as the parts don't break too often and are w…

So it might be a mix of cost-engineering, and (consequently) not having the organizational capability to do software better on the occasions that would actually would be worthwhile?
Post reply on HN