On 2025-03-10 08:41, Andrei Borzenkov wrote:
On Mon, Mar 10, 2025 at 11:03 AM aplanas <aplanas@xxxxxxx> wrote:
On 2025-03-08 18:52, Diorcet Yann wrote:
> - Fake the second (using UUID/PARTLABEL/...) but using LUKS partition
> from the "good" root partition
This is done by "systemd-pcrfs[-root]". The attacker needs to have
access to the system (as a normal user to use something like lsblk)
The attacker will have a different root filesystem that allows
anything.
Right. But my point was that to impersonate the original root they have
to know those values and for that they need access to the system.
I do not know in the OP case, but in some other situations if the user
has enough access to know those values the system can be already be
considered compromised.
tpm2-measure-pcr take the LUKS2 volume key (cryptsetup luksDump
--dump-master-key), and this requires the effective unlock of the
device
(via TPM2 or passphrase)
> - Boot the machine
>
> - The initrd will try unlocks the malicious partition as root. As the
> TPM token will not work, the attacker will use the password of his
> malicious LUKS
>
> - Make the update of the PCR due to the measuring of the malicious
> partition fails
As commented, using tpm2-measure-pcr, PCR15 will be extended with
HMAC("cryptsetup:$name:$uuid", vk), and vk cannot be impersonated.
The catch here is that you need to bind your *root* to the PCR15 too.
I.e. you need both
systemd-cryptenroll --tpm2-pcrs=...+15:sha256=0x0 ... /dev/your-root
and /etc/crypttab in initrd
cr_root /dev/your-root - tpm2-measure-pcr,...
Otherwise the described attack looks possible (probably, depending on
the other PCRs to which root is bound).
That does not make any sense to me ...
For systemd-cryptsetup to measure PCR15 it need to read the vk, and to
read the vk the volume needs to be already unlocked. PCR15 cannot
participate in the unlock policy.
> - Initrd will try to unlock the second partition, which is the "good"
> root partition, and it will succeed, allowing the attacker to finally
> access all data from the partition.
Yes, this partition can be unlocked using a policy that uses PCR0..9
for
TPM2 (without PIN). But not necessarily means that the attacker has
any
access yet, at least not while we are in the initrd.
See above. Attacker has already substituted the root, so /if/ this
unlocks succeeds, the attacker has access to the system.
And I agree on that, but I also wrote that for that to be true the
initrd needs complete the switch root (and delegate the execution the
init process to the compromised device).
My point is that there is a lapse of time where the compromised device
and the real root are open (bad thing), but the control is still in the
trusted initrd (good thing). In this brief moment the attacker has no
control of the system yet.
Another way to mitigate this is to additionally bind to the PCRs that
measure bootloader state like PCR5. As long as the fake root has a
different GUID it should prevent automatic unlocking. Not sure how
UEFI firmware will respond to two completely identical disks.
I thought about PCR 5 too, but IIUC the measured information is easy to
replicate.
I think that there is a more simple model, that was described in a
nice
blog post some months ago. The idea is to never leave the initrd if
the
expected value of PCR15 is not meet.
Yes, but the point is that you need to arrange for that additionally.
That I do not understand.
The last step is to have a service in the initrd that is executed
after
systemd-cryptsetup@.service, but before the switch root, it will
compare
the current PCR15 value with the expected one, and if it fails it will
halt the system.
Well, with e.g. dracut an attacker still can break early, before your
script runs, and manually invoke systemd-cryptsetup.
For that you need to change the cmdline, that was measured and part of
the policy that open the device.
The protection must belong to the LUKS
partition itself. It must be bound to the PCRs which allow detection
of the altered command line among other things. Binding root to PCR7
most certainly is *not* enough.
The current implementation of tpm2-measure-pcr is based on extending
PCR15 with the LUKS2 volume key, and the key point is that to extract
this volume key you already need to open the device. That is the point
that I think you are missing.
But I see that maybe there are other alternatives, like reading the
LUKS2 raw header with the keyslots and encrypted vk. That measure could
participate in the policy, and even if it can be replicated, I do not
see how can be used, but this is not how tpm2-measure-pcr works.
