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

101–110 of 135 posts

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

#101

Post by Groxx »

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…

On further reading and wondering what some of these terms / tools are: since this is describing a system with un-attended decryption, it seems like it literally requires passwordless access to the disk encryption keys.

If that re-reading is correct: yeah, there's not much choice but to put all hope in your code + the TPM, since you essentially can't wait for a password. You get what you pay for in that case - no password means no password, so you're inherently vulnerable to exploits like this.

The linked article, https://hmarco.org/bugs/CVE-2016-4484/CVE-2016-4484_cryptset... , seems to describe this kind of setup: the exploit gets you root in the boot partition only, but not any encrypted volumes, so encrypted data is still encrypted. An attacker could get access to anything not protected otherwise though, e.g. unencrypted volumes and hardware, which is a potentially big problem for cloud environments but not so much personal device theft (they already have the hardware).

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

#102

Post by autumn-antlers »

hedora wrote: post #42
gameoverhumans wrote: post #38

Earlier quoted context omitted.

In a "properly" hardened setup, you would protect the GRUB command line with ... yet another password! :) https://help.ubuntu.com/community/Grub2/Passwords But see my sibling comment about the possibilities of trivially bypassing Secure Boot.

Grub passwords don't protect against the attack I was thinking of, since you can just pop the drive + edit the grub config: "Errors in creating a password-protected GRUB 2 menu may result in an unbootable system. To restore a system with broken passwords, access and edit the GRUB 2 configuration files using the LiveCD or another OS." However, it didn't occur to me that you can just press "e" at the grub prompt, then…

> since you can just pop the drive + edit the grub config

My current Secure Boot configuration only allows booting a signed GRUB EFI image which contains the configuration. Modifying it on disk would invalidate the signature, causing Secure Boot would fail. My `/boot` isn't encrypted, but each file that GRUB accesses (eg. the initrd image, vmlinux, background.png...) also has a `.sig` file and GRUB refuses to load any unsigned (or invalid) resources. This means that GRUB doesn't need a password to get into the initrd, and I can just enter one password from in there.

Next, I'm considering tying user data decryption to login and allowing the root system to be unlocked by the TPM. It seems like a good compromise to me, as I don't keep persistent data on `/` anyways. The host SSH key will be there, but still protected by the TPM and the above chain.

Edit: This would be better with aggressive measured boot parameters-- I don't care about losing `/` to a tempermental TPM, and that SSH host key is otherwise somewhat vulnerable. I'll have to learn more about measured boot and PCR.

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

#103

Post by o11c »

theLiminator wrote: post #94
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…

Is there a way to do 2FA yubikey style disk encryption? Ie. requires a passphrase + user's yubikey to login?

Yes, see https://askubuntu.com/questions/599825/yubikey-two-factor-au...

Note that this is via a second slot, the original passphrase-only key still works unless you take steps to remove it.

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

#104

Post by LanternLight83 »

Ther, was this awsome passkey I saw recently that you could only use by uploading programs to it (vs. using the TPM API), and then that program's hash would occupy a PCR slot. This would allow minimal protocols, specialized to their use cases, with updatable API's-- but I'm blanking on the name!

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

#105

Post by Dalewyn »

CatWChainsaw wrote: post #90
causi wrote: post #9

Earlier quoted context omitted.

Cloudflare also gives captcha loops if you have a number of different VPN extensions installed.

Trying to access Archive on Mozilla with my only extension disabled (uBO) also results in captcha loop...

The problem is probably Mozilla (Firefox?), it's a third-class citizen these days.

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

#106

Post by reanimus »

gameoverhumans wrote: post #40
chatmasta wrote: post #39

Earlier quoted context omitted.

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…

No, this explot has nothing to do with the TPM. The problem is tricking the initrd in giving you a shell, at which point you are able to run arbitrary "unprivileged" code (i.e your shell commands) and tell the TPM to do whatever you want. Gaining a shell using the technique in this article is functionally equivalent to the bypass Secure Boot -> boot live Linux scenario I described in parent comment. The article notes…

The exploit has everything to do with the TPM. It sounds like you don't understand why that is.

The TPM measures everything that you feed it. The firmware feeds it whatever binaries it boots, and those binaries may in turn feed it other data (configuration, chainloaded kernels, initrd, etc). Just booting a live disk on a TPM-encrypted computer won't be sufficient to access the data, as the loaded binaries/kernel arguments/etc will be different, so the TPM measurements will b e different. As such, it won't unlock.

The problem here is that the TPM doesn't measure things running in Linux (at least, not by default), so it doesn't know the difference between "expected initrd booting correctly" and "expected initrd being exploited".

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

#107

Post by tomatocracy »

autumn-antlers wrote: post #102
hedora wrote: post #42

Earlier quoted context omitted.

Grub passwords don't protect against the attack I was thinking of, since you can just pop the drive + edit the grub config: "Errors in creating a password-protected GRUB 2 menu may result in an unbootable system. To restore a system with broken passwords, access and edit the GRUB 2 configuration files using the LiveCD or another OS." However, it didn't occur to me that you can just press "e" at the grub prompt, then…

> since you can just pop the drive + edit the grub config My current Secure Boot configuration only allows booting a signed GRUB EFI image which contains the configuration. Modifying it on disk would invalidate the signature, causing Secure Boot would fail. My `/boot` isn't encrypted, but each file that GRUB accesses (eg. the initrd image, vmlinux, background.png...) also has a `.sig` file and GRUB refuses to load an…

This is what I do for my laptop - I build a custom GRUB image which enforces GPG signatures (including on grub.cfg) using grub-mkstandalone. This also has a built-in configuration which enforces passwords for editing boot commands. That GRUB efi image is signed by a custom secure boot key which I enroll. Kernel and initrd are signed by the gpg key (and the kernel also has to be signed by the secure boot key otherwise it won't load in this scenario).

The root FS is then encrypted using clevis to lock to the TPM PCRs (only). I use PCRs 0,2,4,7 for this. So the laptop will boot to a login screen without needing a password.

My home directory is separately encrypted and gets unlocked with the login password using pam_zfs_key. It works pretty well and I'm happy with the security for my threat model (casual theft is really my main concern).

I am very aware that my home directory stays unlocked unless I actually power down the machine though.

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

#108

Post by Aurornis »

michaelt wrote: post #57
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?

If you've got a user who can enter a long passphrase, you don't need a TPM, so this TPM bypass is moot. The evil maid attack on an encrypted disk with a passphrase is that the attacker installs a hardware keylogger, then comes back the next day and snatches your laptop, which the keylogger tells them the password for. If you've got highly sensitive chassis intrusion detection that wipes your secrets at the drop of a…

> If you've got a user who can enter a long passphrase, you don't need a TPM, so this TPM bypass is moot.

That's a weird dismissal.

This attack is a big deal because it provides a workaround to full desk encryption.

I have no idea why so many people in this thread are trying to pretend it's not a big deal. This is a big deal. Full disk encryption is supposed to make sure your data is safe if the laptop is stolen. This attack makes your data vulnerable if your laptop is stolen.

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

#109

Post by Helmut10001 »

Dalewyn wrote: post #105
CatWChainsaw wrote: post #90

Earlier quoted context omitted.

Trying to access Archive on Mozilla with my only extension disabled (uBO) also results in captcha loop...

The problem is probably Mozilla (Firefox?), it's a third-class citizen these days.

I am on Chrome.

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

#110

Post by BenjiWiebe »

Aurornis wrote: post #108
michaelt wrote: post #57

Earlier quoted context omitted.

If you've got a user who can enter a long passphrase, you don't need a TPM, so this TPM bypass is moot. The evil maid attack on an encrypted disk with a passphrase is that the attacker installs a hardware keylogger, then comes back the next day and snatches your laptop, which the keylogger tells them the password for. If you've got highly sensitive chassis intrusion detection that wipes your secrets at the drop of a…

> If you've got a user who can enter a long passphrase, you don't need a TPM, so this TPM bypass is moot. That's a weird dismissal. This attack is a big deal because it provides a workaround to full desk encryption. I have no idea why so many people in this thread are trying to pretend it's not a big deal. This is a big deal. Full disk encryption is supposed to make sure your data is safe if the laptop is stolen. Thi…

It's only a workaround for passwordless/unattended FDE, right?

Regular password-protected FDE wouldn't be vulnerable this way.

Post reply on HN