Arch Linux

moy0

Member

Registered: 2021-02-16

Posts: 23

[SOLVED] Bootkitty mitigation

I don't know enough UEFI and bootloaders to figure this out myself. What's the best migitation against Bootkitty? I use Secure Boot with the shim, which launches refind, which launches a UKI. The shim, refind, and the UKI are all on an unencrypted (EFI) partition on a USB drive, and my root partition is dm-crypted.

Last edited by moy0 (2024-12-27 17:38:34)

-thc

Member

Registered: 2017-03-15

Posts: 775

Re: [SOLVED] Bootkitty mitigation

The initial vector is to overwrite the GRUB EFI binary (grubx64.efi) - it's a "GRUB-based kernel backdoor".

Since you don't use GRUB this should be no great concern to you.

But if you are anyway - think about making the EFI partition inaccessible (r/o or not mounted) in everyday situations and/or using your own secure boot keys exclusively - the later stage relies on a microsoft-signed binary. If you use your own keys you can boot directly into the UKI.

Last edited by -thc (2024-12-27 09:50:23)

Head_on_a_Stick

Member

From: The Wirral

Registered: 2014-02-20

Posts: 8,743

Website

Re: [SOLVED] Bootkitty mitigation

The exploit also depends on your firmware being vulnerable to LogoFAIL — if you place an image at /EFI/OEM/Logo.jpg on the ESP do you see it on your screen when the machine boots up? If not then you probably don't have to worry. The only other attack surface is via firmware updates that place images on the ESP so use manual firmware image updates instead of fwupd if you're feeling paranoid.

Last edited by Head_on_a_Stick (2024-12-27 10:38:35)

---

Para todos todo, para nosotros nada

moy0

Member

Registered: 2021-02-16

Posts: 23

Re: [SOLVED] Bootkitty mitigation

The initial vector is to overwrite the GRUB EFI binary (grubx64.efi)

My understanding is that if you use the shim then the next stage necessarily has to be named grubx64.efi even if you don't use GRUB. Does that affect this in any way? (i.e. does the vulnerability come from the name or from the actual GRUB efi?)

-thc

Member

Registered: 2017-03-15

Posts: 775

Re: [SOLVED] Bootkitty mitigation

My understanding is that if you use the shim then the next stage necessarily has to be named grubx64.efi even if you don't use GRUB.

You're right - i didn't recall that part of the shim mechanism. But the shim loader checks either the MOK hash or the signature of "grubx64.efi" and jumps to the MokManager (mm64.efi) if those are incorrect.

Does that affect this in any way? (i.e. does the vulnerability come from the name or from the actual GRUB efi?)

From the code inside the malicious grubx64.efi.

moy0

Member

Registered: 2021-02-16

Posts: 23

Re: [SOLVED] Bootkitty mitigation

Got it. Thank you both.