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

Mashing Enter to bypass full disk encryption with TPM, Clevis dracut and systemd

pulsesecurity.co.nz

Post reply on HN
Print view View original

61–70 of 135 posts

Re: Mashing Enter to bypass full disk encryption with TPM, Clevis dracut and systemd

#61

Post by PlutoIsAPlanet »

jmetzmeier wrote: post #52
alexvitkov wrote: post #22

There's no viable reason to reboot a Linux box. Even for kernel upgrades you have kexec, and there are ways (hacks) to hand over the LUKS keys to the new kernel. If you need to reboot an encrypted box remotely AND have it automatically decrypt without you knowing the key, you've already lost the game.

What about libc updates? If you need to restart effectively every process on the system anyways, why not reboot?

Only rolling distros should be shipping mid-release cycle updates that break libc compatibility.

It's not a normal thing for release-based distributions where userspaceuserspace compatibility is nearly assured during a release.

Re: Mashing Enter to bypass full disk encryption with TPM, Clevis dracut and systemd

#62

Post by temp_gnuser »

I have long advocated for disabling tpm in bios, uefi-boot raw dm-crypt to even get grub much less init. This is also how I have done encrypted disks in the cloud using dropbear ssh as an initram shim for key/pass entry. Bios boot pass is annoying but required. Watch your acess/auth logs. Run a HIDS. Isolate your procs and especially their network comms. Security is an onion, not that most c-suites have any idea these days, blinded by fast talkers.

Re: Mashing Enter to bypass full disk encryption with TPM, Clevis dracut and systemd

#63

Post by magicalhippo »

gameoverhumans wrote: post #59
hollerith wrote: post #48

Earlier quoted context omitted.

>But IMO unless you run a very hardened setup, protecting against evil maid attacks (wherein the attacker has physical access to your machine in its entirety) is really hard, and possibly always will be. Can you describe an evil maid attack on an encrypted disk that gets unlocked by the user's entering a passphrase?

In my view, a setup where you are forced to enter a decent-quality disk-unlock passphrase on every cold boot is a rather hardened setup. The problem is, this is awful UX. If something causes a lot of friction, folks tend to just avoid that thing. And that's why many people just bind the disk encryption key to their TPM and call it a day. Thus leading to the exploit detailed in the parent article. Once you have physic…

There's also voltage glitching which has been used with great success as well[1][2].

[1]: https://web.archive.org/web/20190801014726/https://www.cl.ca...

[2]: https://arxiv.org/abs/2108.04575

Re: Mashing Enter to bypass full disk encryption with TPM, Clevis dracut and systemd

#64

Post by gameoverhumans »

magicalhippo wrote: post #63
gameoverhumans wrote: post #59

Earlier quoted context omitted.

In my view, a setup where you are forced to enter a decent-quality disk-unlock passphrase on every cold boot is a rather hardened setup. The problem is, this is awful UX. If something causes a lot of friction, folks tend to just avoid that thing. And that's why many people just bind the disk encryption key to their TPM and call it a day. Thus leading to the exploit detailed in the parent article. Once you have physic…

There's also voltage glitching which has been used with great success as well[1][2]. [1]: https://web.archive.org/web/20190801014726/https://www.cl.ca... [2]: https://arxiv.org/abs/2108.04575

Indeed! Voltage glitching was used to jailbreak Tesla recently! I believe it was also used to jailbreak the Nintendo Switch.

If a discrete TPM (separate chip on the mobo, rather than an fTPM which runs in the CPU/SoC) is in use, one can also use bus sniffing to pwn TPM protection: https://blog.scrt.ch/2021/11/15/tpm-sniffing/

Re: Mashing Enter to bypass full disk encryption with TPM, Clevis dracut and systemd

#65

Post by Groxx »

So to double check my understanding of this article and the linked one that led to it[1], the issue is:

1. the TPM does not require a password to get the decryption keys

2. bootup decryption passwords are checked by code, before asking (using?) the TPM's data (passwordless, because the bootup code is trusted)

3. exhausting multiple layers of retries causes ^ part 2's code to accidentally get/use the decryption data from the TPM

And assuming that's correct....

WTF

Isn't that stupidly insecure design, because even with trusted-boot checks it's probably trivially bypassed with hardware access (edit: like cutting traces)? Why even offer a bootup password if that's how it's implemented?

Like... at the absolute minimum, a sane design would not completely trust the TPM. Combine the TPM's key with the password to get the real key. No additional steps for users, and it eliminates all TPM-only attacks (subject to your password strength... but currently that is 0 so anything is an improvement).

[1]: https://hmarco.org/bugs/CVE-2016-4484/CVE-2016-4484_cryptset...

Re: Mashing Enter to bypass full disk encryption with TPM, Clevis dracut and systemd

#66

Post by kaylynb »

The article title is very misleading. This isn't bypassing FDE in any way. It's just getting a root shell on a machine you have physical access to with a particular boot configuration.

Clever? Yes. But no encryption is bypassed.

Most systems will only be listening to PCR 7 anyway, so a similar attack could be done by loading your own custom bootloader, or possibly reading messages on the SPI bus when booting. This is just a nice trick that's easier/faster.

There is a balance of convenience versus security and this could be prevented easily by disabling recovery shell or registering more PCRS (with correct boot setup), but would be much more annoying to remotely administer since you could get failure states where the TPM won't release the keys in a variety of situations.

Ultimately TPM-only unlock is a significant increase in security vs unsophisticated attackers and probably fine for 99% of people, but isn't something to rely on if you are concerned about sophisticated attackers.

Even with perfect PCR setup and enrolling only custom keys in UEFI, a running machine is still vulnerable. Cold boot or DMA attacks (Thunderbolt or PCI) are just a few that come to mind. These sound extremely sophisticated but are easily done even with hobbyist equipment. Any running machine with currently unlocked disks should be assumed to be possible to compromise with physical access.

If interested in Linux boot chain Poettering has a good read: https://0pointer.net/blog/brave-new-trusted-boot-world.html

There are a lot of interesting talks around Linux boot security in the upcoming All Systems Go! conference: https://all-systems-go.io/

Microsoft has info regarding boot security in BitLocker Countermeasures: https://learn.microsoft.com/en-us/windows/security/operating...

Re: Mashing Enter to bypass full disk encryption with TPM, Clevis dracut and systemd

#67

Post by [deleted] »

Groxx wrote: post #65

So to double check my understanding of this article and the linked one that led to it[1], the issue is: 1. the TPM does not require a password to get the decryption keys 2. bootup decryption passwords are checked by code , before asking (using?) the TPM's data (passwordless, because the bootup code is trusted) 3. exhausting multiple layers of retries causes ^ part 2's code to accidentally get/use the decryption data…

[deleted]

Re: Mashing Enter to bypass full disk encryption with TPM, Clevis dracut and systemd

#68

Post by jiveturkey »

chatmasta wrote: post #39
gameoverhumans wrote: post #31

Meh, it's an interesting exploit for sure (the USB key simulating Enter key being pressed every 15ms is cute). But IMO unless you run a very hardened setup, protecting against evil maid attacks (wherein the attacker has physical access to your machine in its entirety) is really hard, and possibly always will be. In a hardened setup you lock down the emergency initrd shell - either it's not allowed at all, or it uses…

You raise a valid point, but this attack is particularly alarming because it circumvents a TPM, which is a hardware module that was specifically designed to protect against evil-maid class of attacks, e.g. every iPhone after the 5S uses its Secure Enclave (a TPM) to enforce time delays between passcode attempts [0], so that a physical attacker can't brute force the passcode. (Incidentally, the attack described in the…

In addition to the inaccuracies others have mentioned, the iPhone secure enclave is not a TPM. Saying it is isn't a simplification, it's muddying the waters.

Re: Mashing Enter to bypass full disk encryption with TPM, Clevis dracut and systemd

#69

Post by jiveturkey »

temp_gnuser wrote: post #62

I have long advocated for disabling tpm in bios, uefi-boot raw dm-crypt to even get grub much less init. This is also how I have done encrypted disks in the cloud using dropbear ssh as an initram shim for key/pass entry. Bios boot pass is annoying but required. Watch your acess/auth logs. Run a HIDS. Isolate your procs and especially their network comms. Security is an onion, not that most c-suites have any idea thes…

if security is an onion, why do you advocate for throwing the baby out with the bathwater?

Re: Mashing Enter to bypass full disk encryption with TPM, Clevis dracut and systemd

#70

Post by brenns10 »

Groxx wrote: post #65

So to double check my understanding of this article and the linked one that led to it[1], the issue is: 1. the TPM does not require a password to get the decryption keys 2. bootup decryption passwords are checked by code , before asking (using?) the TPM's data (passwordless, because the bootup code is trusted) 3. exhausting multiple layers of retries causes ^ part 2's code to accidentally get/use the decryption data…

TPMs typically won't give out a secret unless all of the software which has been loaded and executed was "measured" and found to be unmodified from when the secret was stored. So you couldn't simply stick your own hard disk or USB disk into the computer and then ask the TPM for the secret: the running software wouldn't match, and the TPM would refuse.

This is a problem because the "approved" software has this strange vulnerability to get into the rescue shell, right at the point where the TPM would be happy to give you the secret because the software is unmodified.

Post reply on HN