On Wed, Oct 16, 2024 at 06:19:33PM +0200, Daniel Kiper wrote: > On Fri, Sep 06, 2024 at 05:11:21PM +0800, Gary Lin via Grub-devel wrote: > > When using disk auto-unlocking with TPM 2.0, the typical grub.cfg may > > look like this: > > > > tpm2_key_protector_init --tpm2key=(hd0,gpt1)/boot/grub2/sealed.tpm > > s/grub2/grub/ > > > cryptomount -u <PART-UUID> -P tpm2 > > search --fs-uuid --set=root <FS-UUID> > > > > Since the disk search order is based on the order of module loading, the > > attacker could insert a malicious disk with the same FS-UUID root to > > trick grub2 to boot into the malicious root and further dump memory to > > s/grub2/GRUB/ and below please...
Will fix them in the next version. Gary Lin > > > steal the unsealed key. > > > > Do defend against such an attack, we can specify the hint provided by > > 'grub-probe' to search the encrypted partition first: > > > > search --fs-uuid --set=root --hint='cryptouuid/<PART-UUID>' <FS-UUID> > > > > However, for LVM on an encrypted partition, the search hint provided by > > 'grub-probe' is: > > > > --hint='lvmid/<VG-UUID>/<LV-UUID>' > > > > It doesn't guarantee to look up the logical volume from the encrypted > > partition, so the attacker may have the chance to fool grub2 to boot > > into the malicious disk. > > > > To minimize the attack surface, this commit tweaks the disk device search > > in diskfilter to look up cryptodisk devices first and then others, so > > that the auto-unlocked disk will be found first, not the attacker's disk. > > > > Cc: Fabian Vogt <fv...@suse.com> > > Signed-off-by: Gary Lin <g...@suse.com> > > Reviewed-by: Stefan Berger <stef...@linux.ibm.com> > > Otherwise Reviewed-by: Daniel Kiper <daniel.ki...@oracle.com>... > > Daniel _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
