Another Crack in the Chain of Trust: Uncovering (Yet Another) Secure Boot Bypass • Hacker News Board

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

#81

Post by npteljes » Wed, Jun 11, 2025, 12:25 PM UTC

fsflover wrote: post #75

npteljes wrote: post #74

Earlier quoted context omitted.

I believe not. Even with full disk encryption, you need an unencrypted bootloader after uefi to decrypt the disk. https://security.stackexchange.com/questions/267222/full-dis... So, there are two scenarios here. First, PC with FDE + normal boot gets stolen. The attacker cannot get the data without the password, so it's safe. Second, unattended FDE + normal boot PC gets tampered with. Attacker manipulates the bootload…

The second case requires a professional, dedicated attacker. I use TPM with Heads and a hardware key to protect myself against it. It will notify me if the boot partition or BIOS are tampered with. As an advantage, all relevant code running on my computer is FLOSS and auditable, unlike the Secure Boot and UEFI.

That's a cool setup! I didn't know about Heads.

And yes, getting back to the original topic, I believe that against petty criminals, even a full disk encryption is plenty defense. They won't go about installing anything to the EFI partition just to get to the data.

This Coreboot + Heads setup I'd trust to protect against even the more involved.

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

#82

Post by RiverCrochet » Wed, Jun 11, 2025, 2:14 PM UTC

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 something that can't be written except when you specifically enable it.

A better scheme than the UEFI secure boot/TPM junk is simply a 2GB SD card (enough to hold a bootloader, kernel, and initrd) in an SD card reader with a physical read/write switch. When it's time to update your bootloader or kernel, flip the switch to write mode, then flip it back - heck the system could even refuse to boot if write mode was enabled on boot.

Honestly I don't know why the whole PC firmware shouldn't be on that SD card. Corrupt unbootable BIOSes can be fixed with a new SD card.

For remote updates, the physical switch could be replaced with a GPIO pin and a Raspberry Pi that you connect to and log into separately. It's less secure than the physical switch but oodles more secure than what's there now - maybe not oodles but at least the software on a Pi is much higher quality than UEFI vendors.

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

#83

Post by HPsquared » Wed, Jun 11, 2025, 2:27 PM UTC

Y_Y wrote: post #80

HPsquared wrote: post #72

Earlier quoted context omitted.

Some kind of secure enclave is necessary to prevent brute force attacks. Allows simple PIN unlock for users.

I'd argue that it's neither necessary nor sufficient for securing your data. (Convenience is another worthwhile consideration, of course.) Cryptography should be enough to protect you from brute force, if you care about such things. I don't think it would be controversial to say that it's much more likely your particular secure enclave is broken than your encryption scheme (assuming you choose something appropriate a…

It's just really convenient to key in a 6-digit PIN.

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

#84

Post by xinayder » Wed, Jun 11, 2025, 2:48 PM UTC

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 has root privileges to my Linux system, what's stopping them from overwriting my Linux kernel image in my boot partition with one that has backdoors?

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

#85

Post by heavyset_go » Wed, Jun 11, 2025, 3:17 PM UTC

fsflover wrote: post #71

heavyset_go wrote: post #67

Earlier quoted context omitted.

Stick a BIOS password on your machine and turn on Secure Boot. Unless there's an exploit in your firmware, you are now secure against petty criminals stealing your data to even somewhat sophisticated attacks from non-state actors via data exfiltration, software keyloggers, etc. You can go another step further and use Secure Boot in a chain of trust up to the kernel with Linux, ensuring everything up to the kernel fro…

> you are now secure against petty criminals stealing your data Ordinary disk encryption would protect me too here, wouldn't it?

Unless your BIOS/UEFI supports full disk encryption unlocking of hardware-encrypted Opal drives, you will always have an unencrypted bootstrap process at early boot from the disk.

That unencrypted bootstrap process can be modified by anyone with access to the disk, physical or remote. Theoretically, someone can inject a keylogger into the process and exfiltrate your encryption key's password, or a process that waits until you're decrypted and exfiltrates your data. It's also a potential vector for ransomware, root/boot kits, etc.

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

#86

Post by fsflover » Wed, Jun 11, 2025, 3:25 PM UTC

heavyset_go wrote: post #85

fsflover wrote: post #71

Earlier quoted context omitted.

> you are now secure against petty criminals stealing your data Ordinary disk encryption would protect me too here, wouldn't it?

Unless your BIOS/UEFI supports full disk encryption unlocking of hardware-encrypted Opal drives, you will always have an unencrypted bootstrap process at early boot from the disk. That unencrypted bootstrap process can be modified by anyone with access to the disk, physical or remote. Theoretically, someone can inject a keylogger into the process and exfiltrate your encryption key's password, or a process that waits…

https://news.ycombinator.com/item?id=44246281

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

#87

Post by mjg59 » Wed, Jun 11, 2025, 3:36 PM UTC

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…

> Secure boot requires that the bootloader match a hash derived from a TPM-stored key.

This isn't even slightly accurate. Secure boot does not rely on TPM keys on any way.

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

#88

Post by mjg59 » Wed, Jun 11, 2025, 3:36 PM UTC

xinayder wrote: post #84

RiverCrochet wrote: post #82

Earlier quoted context omitted.

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 has root privileges to my Linux system, what's stopping them from overwriting my Linux kernel image in my boot partition with one that has backdoors?

Secure boot.

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

#89

Post by xinayder » Wed, Jun 11, 2025, 3:45 PM UTC

mjg59 wrote: post #88

xinayder wrote: post #84

Earlier quoted context omitted.

If an attacker has root privileges to my Linux system, what's stopping them from overwriting my Linux kernel image in my boot partition with one that has backdoors?

Secure boot.

How is secure boot stopping them from overwriting my kernel image on the first place? Won't it just report that the kernel image was tampered and thus you cannot boot to the system?

It does nothing to prevent overwriting the kernel image.

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

#90

Post by hollerith » Wed, Jun 11, 2025, 3:49 PM UTC

xinayder wrote: post #89

mjg59 wrote: post #88

Earlier quoted context omitted.

Secure boot.

How is secure boot stopping them from overwriting my kernel image on the first place? Won't it just report that the kernel image was tampered and thus you cannot boot to the system? It does nothing to prevent overwriting the kernel image.

If secure boot is operating as designed, the boot loader will refuse to boot the replacement kernel (because its hash is not on a list).

Now if you ask, how is secure boot stopping an attacker from overwriting libc or some other important system library? the answer is nothing is stopping it on Linux, but on ChromeOS, MacOS, Windows and the two mobile OSes, the secure-boot machinery has been guarding against that for years.