On 2025-03-13 10:10, Andrei Borzenkov wrote:
On Tue, Mar 11, 2025 at 12:17 AM aplanas <aplanas@xxxxxxx> wrote:
[1]
https://oddlama.org/blog/bypassing-disk-encryption-with-tpm2-unlock/
This attack is possible because root is bound to the boot time TPM
state that is not modified after the system is booted.
I would reword it. The attack is possible because we are not checking
the integrity of the device before we give the control to it.
As commented, destroying the policy would indeed make the recovery of
the TPM2 sealed key impossible, but then the daily operation will suffer
and the recovery PIN needs to be entered after each update.
You argued that this PIN could be unsealed by a different policy, but
then this policy needs to be broken in the new situation, or else the
attacker can meet the policy and recover the PIN, that can update the
policy that can validate a rogue initrd.
To mitigate
this, the root has to be additionally bound to some run-time state
that only allows unlocking during the specific boot stage. Whether it
is PCR11 for pcrextend or PCR15 for other filesystem or something else
doesn't really matter. But PCR15 looks better - it will be
automatically set as soon as the (fake) root is unlocked, thus
changing run-time state for any subsequent attempt to mount the real
root.
Right, PCR15 will be changed just when the device is unlocked, but
again, the problem is that there is no order in PCR15 extension. If you
create a policy that adds PCR15 expecting 0x0...0 to unlock root, then
this can work, or not. If you have an encrypted swap, then the value of
PCR15 is not determined unless you impose an order.
Can you ensure that we never ever enter initrd emergency shell?
Would
[Unit]
OnFailure=systemd-halt.service
or
[Service]
FailureAction=reboot-immediate
prevent that?
And if we consider the possibility of spoofing TPM communication - the
values are in clear text and so can be spoofed (as long as it is
technically possible at all). I suppose it can be improved by
encrypting via TPM.
That was discussed in a different thread. The session is encrypted, so
commands that uses or return private data are encrypting this parameter
/ return value.
I like the idea behind systemd-verifyfs, but I would not make it
dependent of fs attributes, but device one (with the caveat of the
extension order). But I agree that separating the policy that unlock
the device from the policy that unlock the PIN deserve to be explored.
