Doesn’t this mean that secure boot would save your ass? If you verify that the boot files are signed (secure boot) then you can’t boot these modified files or am I missing something?
Well, not an expert. We learned now that logos are not signed. I’m not sure the boot menu config file is not either. So on a typical linux setup you can inject a command there.
If it can execute in ram (as far as I understand, they’ve been talking about fileless attacks, so… Possible?), it can just inject whatever
Addit: also, sucure boot on most systems, well, sucks, unless you remove m$ keys and flash yours, at least. The thing is, they signed shim and whatever was the alternative chainable bootloader (mako or smth?) effectively rendering the whole thing useless; also there was a grub binary distributed as part of some kaspersky’s livecd-s with unlocked config, so, yet again, load whatever tf you want
Last time I enabled secure boot it was with a unified kernel image, there was nothing on the EFI partition that was unsigned.
Idk about the default shim setup but using dracut with uki, rolled keys and luks it’d be secure.
After this you’re protected from offline attacks only though, unless you sign the UKI on a different device any program with root could still sign the modified images itself but no one could do an Evil Maid Attack or similar.
The point with m$ keys was that you should delete them as they’re used to sign stuff that loads literally anything given your maid is insistent enough.
[note: it was mentioned in the arch wiki that sometimes removing m$ keys bricks some (which exactly wasn’t mentioned) devices]
Doesn’t this mean that secure boot would save your ass? If you verify that the boot files are signed (secure boot) then you can’t boot these modified files or am I missing something?
Well, not an expert. We learned now that logos are not signed. I’m not sure the boot menu config file is not either. So on a typical linux setup you can inject a command there.
If I can replace a file in your EFI, how hard would it be to sign the same file.
Well, it rules out an evil maid attack and maybe jumping over a dual boot setup.
If it can execute in ram (as far as I understand, they’ve been talking about fileless attacks, so… Possible?), it can just inject whatever
Addit: also, sucure boot on most systems, well, sucks, unless you remove m$ keys and flash yours, at least. The thing is, they signed shim and whatever was the alternative chainable bootloader (mako or smth?) effectively rendering the whole thing useless; also there was a grub binary distributed as part of some kaspersky’s livecd-s with unlocked config, so, yet again, load whatever tf you want
Last time I enabled secure boot it was with a unified kernel image, there was nothing on the EFI partition that was unsigned.
Idk about the default shim setup but using dracut with uki, rolled keys and luks it’d be secure.
After this you’re protected from offline attacks only though, unless you sign the UKI on a different device any program with root could still sign the modified images itself but no one could do an Evil Maid Attack or similar.
The point with m$ keys was that you should delete them as they’re used to sign stuff that loads literally anything given your maid is insistent enough.
[note: it was mentioned in the arch wiki that sometimes removing m$ keys bricks some (which exactly wasn’t mentioned) devices]