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

81–90 of 135 posts

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

#81

Post by alexeldeib »

adrian_b wrote: post #79
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…

Because of things like those described by you, I have never trusted bootable encrypted SSDs/HDDs. In my computers, I have only non-bootable and non-partitioned SSDs/HDDs, which are completely encrypted with a random 256-bit key, so as long as an attacker has only access to the computer, for instance to a stolen laptop, there is absolutely nothing that can be done to gain access to the stored data. To boot the compute…

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

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

#82

Post by Kiuhrly1 »

gameoverhumans wrote: post #64
magicalhippo wrote: post #63

Earlier quoted context omitted.

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/

For the Nintendo Switch, it was used to dump some firmware which was then analysed and found to have a buffer exploit (can't remember what sort), which let to the famous Fusee Gelee exploit on early switches. IIRC it was a security chip which is both ironic and incredibly useful because it couldn't be patched without a hardware revision and it ran before anything loaded from the onboard storage.

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

#83

Post by StillBored »

malwrar wrote: post #77
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?

The thing that prompts for your password is necessarily unencrypted, the evil maid just needs to modify that to e.g. log the decryption key. On linux, this is usually just a shell script invoking cryptsetup somewhere in the initramfs image.

Maybe, it is possible to use both a firmware unlock against an OPAL encrypted drive, and validate the signature of the initrd/UKI as part of secure boot. Either or both protect against this to a certain extent depending on configuration.

As does of measuring all of the above into PCRs that are unlocked with by the utility prompting for a pin used alongside the PCRs to unlock the key.

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

#84

Post by StillBored »

adrian_b wrote: post #79
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…

Because of things like those described by you, I have never trusted bootable encrypted SSDs/HDDs. In my computers, I have only non-bootable and non-partitioned SSDs/HDDs, which are completely encrypted with a random 256-bit key, so as long as an attacker has only access to the computer, for instance to a stolen laptop, there is absolutely nothing that can be done to gain access to the stored data. To boot the compute…

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 or equivilant (with the encrypted RAM enabled)? Because the disk encryption key is probably just sitting unencrypted in system RAM otherwise, and is susceptible to people freezing the ram and removing it to another machine to extract the keys.

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

#85

Post by wolfgang42 »

ddtaylor wrote: post #43
Galanwe wrote: post #37

The best hacker I know is my 12 month old. Give him any kind of device for 2 minutes and you will discover a plethora of UI issues, hidden menus, and security bypasses.

I came home one day and my cat was laying on my keyboard. Above her was a screen with a large amount of random control characters in a terminal with a kernel panic screen. So there's some series of buttons you can press that will crash a Linux desktop from a lock screen.

My favorite bug report in this vein: https://bugs.launchpad.net/ubuntu/+source/unity-greeter/+bug...

> Steps to reproduce:

> 1. Leave laptop unattended in a cold room with a warm cat.

> 2. Cat will sit on laptop keyboard.

> 3. Wait 1 hour.

> 4. Lightdm will become unresponsive.

Also included: “Alternative steps to reproduce if cat is unavailable or uncooperative about being placed on keyboard (see attached pictures)”

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

#86

Post by Guvante »

rlpb wrote: post #14
Guvante wrote: post #10

Earlier quoted context omitted.

Technically, but really the fault lies in the OS for providing an exploitable prompt that doesn't break the chain of custody of the boot process on failure.

Ubuntu developer here. I don't think that's fair. The OS, as shipped today, isn't designed with this threat model in mind. It's correct to say that for TPM-based LUKS unlock to be safe, the initramfs must not allow the user to take control of it. But that's a new requirement introduced when the user modified their system to configure TPM-based LUKS unlock. This isn't the responsibility of an OS that doesn't ship with…

I think it is fair to say that OS configuration to fix this should be required.

I agree with the logic that by default the OS is doing the right thing without any changes to support this model.

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

#87

Post by Guvante »

formerly_proven wrote: post #13
Guvante wrote: post #10

Earlier quoted context omitted.

Technically, but really the fault lies in the OS for providing an exploitable prompt that doesn't break the chain of custody of the boot process on failure.

This is one of those designs where you skim a description and already know it’s going to break in a million different ways.

100% this is sketch. I was thinking if this was a supported security model you shouldn't be able to take control without disabling the TPM.

But it isn't so not the OSes problem.

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

#88

Post by Klasiaster »

Sounds like it would have also worked to replace the hard drive with an own one where the OS directly gives a root shell to read the TPM secret.

The solution is to bind the TPM secret to a measured boot state, but that requires a way of precalculation of the expected measurement values. Read more about signatures for these precalcuated measurement values here: https://0pointer.net/blog/brave-new-trusted-boot-world.html (TLDR: The publishing of prebuilt OS vendor kernel+initrds and signed PCR policies allows to bind the secret to the signature being valid, so that it still works when auto updates change the measurement as long as the vendor signature is also there.)

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

#89

Post by patrakov »

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.

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

#90

Post by CatWChainsaw »

causi wrote: post #9
trillic wrote: post #8

Earlier quoted context omitted.

Are you using Cloudflare's DNS? Archive.is purposefully gives bad results to Cloudflare's DNS resolvers as they do not respect and pass along EDNS subnet information which Archive wants to run their own CDN. https://jarv.is/notes/cloudflare-dns-archive-is-blocked/

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...
Post reply on HN