The proposed solution is to extend PCR 15 using the volume key from the unlocked drive and abort the boot in the event of an incorrect value; am I correct in understanding that this approach is infeasible since the Incus initrd is immutable?
I can’t test this since I don’t have an Incus machine at the moment. This isn’t a dealbreaker if it’s not a mitigable threat but I figured it was worth mentioning since Incus officially supports TPM-backed disk encryption.
In general, if you see a recovery prompt, you are in an untrusted state already and you should manually confirm that everything on your system is as expected, specifically that the Secureboot keys are all correct and that there is no extra hardware connected to the system.
The attack described at this link will still cause a recovery prompt, after which the system can be made to look like it’s booting correctly despite having had the opportunity to run untrusted code.
But that’s in no way different to someone having enrolled another Secureboot key on the system and then replaced the UKI with one they control.
The same behavior would then happen, untrusted code (in this case the initrd) would be able to run, asking the user for the recovery key, then being able to run whatever it wants before continuing with the normal boot process.
The TLDR is really that if you see a recovery prompt and you didn’t perform an action that you knew would lead to that prompt (reconfiguring Secureboot in our case), then you should treat the system as unsafe and look at undoing whatever was done to it until it boots on its own with no prompting.
Not quite. Yes, the prompt will appear - but that is while the attacker has access to the hardware, and it is what gives the attacker the opportunity to enter their own passphrase which will unlock the partition containing the “poisoned” /sbin/init.
After that, the attacker simply exports the actual LUKS key from TPM (gaining access to the TPM in a state that allows this is the goal of the attack) and uses it to unlock the original LUKS partition.
Oh, right, that is indeed a bit different and more problematic.
It does require a machine reboot and physical access to the machine which shouldn’t really go undetected, but is indeed a bit more problematic in that once it has happened, there’s no real record of the recovery key having been pulled.
@gibmat shouldn’t we be able to avoid this by binding on another normally empty PCR and have the initrd measure some random value into it as soon as it has unlocked a LUKS block device (whether automatically or through recovery).
That way, while we could still be made to boot an arbitrary root disk, the attacker wouldn’t be able to get the PCR state needed to unlock the actual disk from that point.
We’re going to do some tests to be sure, but Incus actually binds on PCR4, PCR7 and PCR11. With PCR4 being mostly there for systems without Secure Boot (degraded boot security).
With the attack mentioned here, you can definitely get to a point where PCR7 is in the expected state when the system is running untrusted code. But it looks like PCR11 may be saving us here as there are additional events being measured into it for entering and leaving the initrd.
So effectively the logging of the “leaving the initrd” event would cause PCR11 to be of a value incompatible with auto-unlock of the disk.
But @gibmat is going to be doing some tests of the attack (basically replacing a root disk with one that provides a shell on exec of /sbin/init) so we can confirm the PCR values at that point and confirm that it’s not possible to have the TPM release the key.
Actually, thinking through it again, all of this assumes that /sbin/init is located on the encrypted LUKS disk. This is NOT the case with IncusOS.
With IncusOS and similar immutable OS images, your root disk is virtually empty, only storing user configuration. The actual OS image is /usr which is read-only (erofs) and is validated through dm-verity, the root key of which is baked into the signed UKI.
So I think that makes the whole attack moot in our case. Our / is actually mounted as noexec and all binaries come from the immutable /usr partition.
At most what you can do is effectively cause a factory reset of the system by having replaced its persistent storage with one of your own making, but that’s not terribly useful.