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

111–120 of 135 posts

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

#111

Post by vlovich123 »

reanimus wrote: post #106
gameoverhumans wrote: post #40

Earlier quoted context omitted.

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

I was ignorant about the argument here, so I went back and read the article. I’m going to have to side with the other guy. The TPM is not involved nor does it work quite as you’re describing (at least in the configuration outlined).

What the article is describing is a normally headless setup (eg server farm) where the TPM owns responsibility for providing the password for unlocking the encrypted root volume. This has nothing to do with software integrity which I think is what you’re describing.

The specific bug here is that the TPM agent and the interactive agent are running at the same time for systemd and the exploit is to get the interactive agent to trigger enough failures before the TPM agent does that you interrupt the normal boot flow. At which point systemd drops you into a recovery shell, you ask the TPM to unlock, and you can now mount the disk manually without having entered any password.

The only reason Windows doesn’t have a problem is they ask the TPM to unlock long before they ever allow for any interactivity. Measuring “initrd is behaving correctly” is not in the purview of a TPM except for “is the executable I’m loading legit” as part of a chain of trust (which again, while valuable and good and important to discuss, is completely separate from this article).

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

#112

Post by Dalewyn »

Helmut10001 wrote: post #109
Dalewyn wrote: post #105

Earlier quoted context omitted.

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

I am on Chrome.

I'm using Chromium, uBO, and 8.8.8.8 with no issues regarding archive.is, so... ┐(￣ー￣)┌

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

#113

Post by CoolCold »

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…

What's your way of providing laptops to your employees? For simplicity, let's assume everyone is located in the same country.

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

#114

Post by privacyking »

patrakov wrote: post #89
twitchyliquid64 wrote: post #51

A simple fix might be to bind the encrypted value to a PCR (hopefully one that isnt too fragile, but prefs one that measures the initrd) and then to invalidate that PCR when you drop to the recovery shell (by extending some junk bytes to it). But if you can't find a PCR thats both not too fragile and measures the initrd, then youll have to settle for sealing the encryption key to a fairly static PCR, in which case th…

On my laptop I have custom Secure Boot keys. I know I did not sign any other OS (well, I did - but with a different key), so this attack won't work, unless the attacker can somehow trick the unmodified previous version of the kernel + initrd combo into asking my passphrase and saving it somewhere, which is highly unrealistic.

If they have physical access as per this scenario, they can just install a hardware keylogger and get access with your login credentials.

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

#115

Post by alasarmas »

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…

It seems to me that the FBI can break into iPhones now, but they want to pretend that they can’t. The FBI strategy appears to be to fake the lack of capability to break in now, in order to be able to claim that there is a crisis and get law or legal precedent in place to allow much broader access, against potentially much better future technological challenges to break-in.

I believe that, from a technical perspective, my argument is supported by this article [0] that I found posted on the ACLU website. This was a reaction to the FBI’s highly-publicized case against Apple in 2015 where the FBI, I believe, pretended that they could not break into the iPhone that had belonged to one of the shooters in the December 2015 San Bernardino attack.

The article I have linked describes a specific technical workaround for avoiding permanent deletion of data, namely, avoiding deletion in “Effaceable Storage” of a key that encrypts some filesystem data. This may or may not continue to be relevant today. A pop-up on an Apple page explaining iPhone privacy [1] specifically states that Effaceable Storage “doesn’t provide protection if an attacker has physical possession of a device”, but I don’t claim to actually understand the security implications of the statements made on that page.

0. https://www.aclu.org/news/privacy-technology/one-fbis-major-...

1. https://support.apple.com/guide/security/data-protection-sec...

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

#116

Post by wkat4242 »

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…

I don't agree. What Ventoy does is simply enabling the user to do what they have the rights to do already in a more user-friendly way.

If the user doesn't have BIOS admin access this won't work. If they do they can just enroll the new key through the menu.

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

#117

Post by wkat4242 »

adrian_b wrote: post #99
StillBored wrote: post #84

Earlier quoted context omitted.

While cool/interesting, i'm failing to understand the attack your protecting against here in the context of just prompting for an unlock PIN. Particularly if that unlock pin is for a FIDO key or whatever which can also be removed. I mean, if someone steals your backpack, or stops you at the border, breaks into your house, whatever, they are getting the boot image too, right? Furthermore, are all your machines AMD Pro…

The attacks "evil maid" described by a poster above are impossible. Even with physical access, the computer does not have any boot loader or kernel or any other executable that could be altered. The attack described in the thread title also does not work, because the computer cannot boot. Even after booting from their own device, attackers cannot do anything useful. Reading the encrypted SSD will not provide any info…

Sounds like a great option. Would be nice if there was an install wizard that could configure that.

Ps I wonder what inconspicuous usb drive you use?

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

#118

Post by gameoverhumans »

adrian_b wrote: post #96
alexeldeib wrote: post #81

Earlier quoted context omitted.

Are you still using LUKS for these? How are you invoking decryption with the pass phrase protected key?

I am not using LUKS, I am using a custom kernel module that implements a block device that presents to the kernel the decrypted SSD. The kernel module receives the key when it is loaded, then it creates the block device that is eventually mounted as the new root device. I do not know if LUKS could be used for this, I have not examined it. IIRC, LUKS stores the actual decryption key in the encrypted disk (protected by…

LUKS supports detached headers, maybe this would be useful for your setup? https://wiki.archlinux.org/title/Dm-crypt/Specialties#Encryp...

Your approach sounds pretty cool, by the way. I've thought about such an approach in the past, and I've used it for some auxiliary computers under my control, but not for my daily driver. I have a Framework laptop and I could indeed use this approach in quite a stylish way, though: https://frame.work/de/en/products/storage-expansion-card?v=F...

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

#119

Post by arianvanp »

twitchyliquid64 wrote: post #51

A simple fix might be to bind the encrypted value to a PCR (hopefully one that isnt too fragile, but prefs one that measures the initrd) and then to invalidate that PCR when you drop to the recovery shell (by extending some junk bytes to it). But if you can't find a PCR thats both not too fragile and measures the initrd, then youll have to settle for sealing the encryption key to a fairly static PCR, in which case th…

There's a WIP PR in the systemd repo that does exactly that. it's called pcrlock. Will come to your local distro soon :)

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

#120

Post by [deleted] »

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…

[deleted]
Post reply on HN