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

11–20 of 135 posts

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

#11

Post by michaelt »

jeroenhd wrote: post #7
betaby wrote: post #5

I don't see any encryption bypass there. Encrypted partition stays encrypted.

The system that should only unlock the drive after the appropriate remote command has been provided, unlocks the drive without the remote command being provided. That's the problem. I'm not sure why you would rely on just the TPM in this case, though. TPM only disk encryption is rather risky, you'd expect a TPM+PIN setup at the very least. You'd still be at risk because of this flaw, because the root shell would allo…

> I'm not sure why you would rely on just the TPM in this case, though. TPM only disk encryption is rather risky, you'd expect a TPM+PIN setup at the very least.

I think the target market is "I have a server in a data centre, I need unattended boot, I don't really need a high grade of security I just need to tick a checkbox saying the hard disk is encrypted"

If your organisation is large enough to start losing track of entire servers, and yet small enough you can't adopt effective organisational controls to prevent such losses, even mediocre encryption might give you some peace of mind - and it lets you avoid reporting data breaches, as the lost data was 'encrypted'.

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

#12

Post by betaby »

LinusU wrote: post #6
betaby wrote: post #5

I don't see any encryption bypass there. Encrypted partition stays encrypted.

Did you read the article? ;) > From here it’s easy to manually use the TPM to unlock the disk with the Clevis tooling and mount the root volume for hacking (it takes a few tries sometimes, but it gets there in the end): They use the exploit to get dropped into a root shell, and then asks the TPM to unlock the disk for them, which it promptly does.

I did. It says 'From here it’s easy to manually use the TPM to unlock the disk with the Clevis tooling and mount the root volume for hacking (it takes a few tries sometimes, but it gets there in the end)'

However screenshot says 'Unsealing failing'. Yet Ubuntu-lv is mounted. I don't follow how Luks password was guessed for it.

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

#13

Post by formerly_proven »

Guvante wrote: post #10
LinusU wrote: post #6

Earlier quoted context omitted.

Did you read the article? ;) > From here it’s easy to manually use the TPM to unlock the disk with the Clevis tooling and mount the root volume for hacking (it takes a few tries sometimes, but it gets there in the end): They use the exploit to get dropped into a root shell, and then asks the TPM to unlock the disk for them, which it promptly does.

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.

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

#14

Post by rlpb »

Guvante wrote: post #10
LinusU wrote: post #6

Earlier quoted context omitted.

Did you read the article? ;) > From here it’s easy to manually use the TPM to unlock the disk with the Clevis tooling and mount the root volume for hacking (it takes a few tries sometimes, but it gets there in the end): They use the exploit to get dropped into a root shell, and then asks the TPM to unlock the disk for them, which it promptly does.

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 that support, and in fact, prior to TPMs, it was perfectly reasonable to allow the user to take control of the initramfs prior to LUKS unlock!

That's not to say that an improvement can't be made as we move towards a future where TPM+LUKS might be the norm - just that you can't retrospectively claim fault on an OS that doesn't claim to support that.

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

#15

Post by [deleted] »

trillic wrote: post #8
knodi123 wrote: post #3

Earlier quoted context omitted.

infinite captcha loop

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/

[deleted]

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

#16

Post by 0xC0ncord »

michaelt wrote: post #11
jeroenhd wrote: post #7

Earlier quoted context omitted.

The system that should only unlock the drive after the appropriate remote command has been provided, unlocks the drive without the remote command being provided. That's the problem. I'm not sure why you would rely on just the TPM in this case, though. TPM only disk encryption is rather risky, you'd expect a TPM+PIN setup at the very least. You'd still be at risk because of this flaw, because the root shell would allo…

> I'm not sure why you would rely on just the TPM in this case, though. TPM only disk encryption is rather risky, you'd expect a TPM+PIN setup at the very least. I think the target market is "I have a server in a data centre, I need unattended boot, I don't really need a high grade of security I just need to tick a checkbox saying the hard disk is encrypted" If your organisation is large enough to start losing track…

The threat vector mitigated by Clevis[1] is someone with physical access (e.g. an insider) removing the server from the data center and being able to access its data.

[1] https://github.com/latchset/clevis

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

#17

Post by betaby »

michaelt wrote: post #11
jeroenhd wrote: post #7

Earlier quoted context omitted.

The system that should only unlock the drive after the appropriate remote command has been provided, unlocks the drive without the remote command being provided. That's the problem. I'm not sure why you would rely on just the TPM in this case, though. TPM only disk encryption is rather risky, you'd expect a TPM+PIN setup at the very least. You'd still be at risk because of this flaw, because the root shell would allo…

> I'm not sure why you would rely on just the TPM in this case, though. TPM only disk encryption is rather risky, you'd expect a TPM+PIN setup at the very least. I think the target market is "I have a server in a data centre, I need unattended boot, I don't really need a high grade of security I just need to tick a checkbox saying the hard disk is encrypted" If your organisation is large enough to start losing track…

Looks like so. From https://rogueai.github.io/posts/arch-luks-tpm/#unlock-the-lu... 'From a security point of view, passwordless LUKS unclocking might look like we’re giving up some security, as booting will go straight to login without asking any password whatsoever. We’re indeed trading a bit of security in favour of convenience, it’s important to note though that binding the LUKS to the TPM ensures the volume will only unlock in our machine, with Secure Boot enabled and our signed boot image.'

So there we are somewhat breaking 'Secure Boot' process in general.

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

#18

Post by bri3d »

betaby wrote: post #12
LinusU wrote: post #6

Earlier quoted context omitted.

Did you read the article? ;) > From here it’s easy to manually use the TPM to unlock the disk with the Clevis tooling and mount the root volume for hacking (it takes a few tries sometimes, but it gets there in the end): They use the exploit to get dropped into a root shell, and then asks the TPM to unlock the disk for them, which it promptly does.

I did. It says 'From here it’s easy to manually use the TPM to unlock the disk with the Clevis tooling and mount the root volume for hacking (it takes a few tries sometimes, but it gets there in the end)' However screenshot says 'Unsealing failing'. Yet Ubuntu-lv is mounted. I don't follow how Luks password was guessed for it.

There wasn't a password necessary, the TPM was an unlocking mechanism.

Secure Boot with TPM-backed disk encryption works off of a series of numbered hashes. The idea of TPM based FDE is that the machine will use Secure Boot to boot only a software chain that the end-user trusts not to contain authentication bypasses. In Secure Boot, the EFI firmware provides hashes of each stage in the boot chain to the TPM, and the TPM only unlocks the full-disk encryption key (really the key encryption key, since the TPM isn't fast enough to actually decrypt the disk) slot if each stage / configuration is valid.

This issue breaks that chain. In some sense it's an illustration of this system being silly conceptually, but it is a real issue IMO.

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

#19

Post by j0057 »

betaby wrote: post #12
LinusU wrote: post #6

Earlier quoted context omitted.

Did you read the article? ;) > From here it’s easy to manually use the TPM to unlock the disk with the Clevis tooling and mount the root volume for hacking (it takes a few tries sometimes, but it gets there in the end): They use the exploit to get dropped into a root shell, and then asks the TPM to unlock the disk for them, which it promptly does.

I did. It says 'From here it’s easy to manually use the TPM to unlock the disk with the Clevis tooling and mount the root volume for hacking (it takes a few tries sometimes, but it gets there in the end)' However screenshot says 'Unsealing failing'. Yet Ubuntu-lv is mounted. I don't follow how Luks password was guessed for it.

No LUKS password was guessed, clevis-disk-unlock command in the last screenshot used the TPM to provide a key to a LUKS keyslot for getting at the actual decryption key to decrypt the disk. The TPM should have had information about the boot state to be able to refuse to provide the key, but didn't.

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

#20

Post by AshamedCaptain »

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…

> This isn't the responsibility of an OS that doesn't ship with that support, and in fact, prior to TPMs, it was perfectly reasonable to allow the user to take control of the initramfs prior to LUKS unlock!

And it still is perfectly reasonable behavior. Any distribution that decides (perhaps as a consequence of this) that on any boot process abnormality the default response is to enter an immediate reboot loop would be called crazy.

Post reply on HN