could someone please explain PreLoader.efi to me? from what i could find, it seems pointless. it's a bootloader signed with microsoft secureboot keys, but it will execute any binary the user adds to its hash database, which apparently doesn't require any kind of authentication. what prevents an attacker from e. g. modifying the kernel and then adding its hash?

· · Web · 3 · 1 · 1

i did some more research. it seems like @wolf480pl is right: out of the box, secure boot protects the user from kernel exploits gaining persistence and nothing else. it makes sense, windows 10 doesn't encrypt disks by default and you can run anything on a system that trusts microsoft keys anyway. it seems like ms will sign anything that requires interactive confirmation from the user. and both PreLoader.efi and shim are meant to replace the microsoft boot loader, not to be more secure.

Show thread

both work by storing either trusted binary hashes or signing keys in a boot service efi variable. it is available for bootloaders, but not for the operating system at run time. it's possible to set up shim to use password authentication, but as far as i understand, the variable storing the password hash can be reset using efi shell. so it doesn't protect you from someone who has enough time.

Show thread

i now understand that there're uses for secure boot other than defending from evil maids. so encrypted root and signed initrd aren't strictly required. e. g. it would make sense to use one of these interactivity-required loaders and a kernel in lockdown mode. if you only configure lockdown, malware could probably modify the kernel file and reboot. secure boot prevents that.

Show thread
@leip4Ier it's probably meant for breaking UEFI implementations that disallow disabling secure boot or installing different keys

although I think just anyone can sign with microsoft keys now...

@null oh, so it isn't meant to be secure? makes sense..

@leip4Ier yeah, it sounds like it's expressly made to not be secure. the only reason I can think of why is for really poor UEFI implementations, which does happen at times

@null @leip4Ier
It is meant to require user consent.
It shouldn't be possible to add keys to MOKlist without user interaction.

@leip4Ier adding a key or hash to the MOK list requires user interaction. It cannot be done automatically, eg. by malware.
At least that's the theory.

@wolf480pl isn't secure boot meant to protect from evil maids and such? and imo if malware is able to modify your kernel, you're doomed anyway..

@wolf480pl i mean, if you have two different systems installed on encrypted disks, it would make sense for malware on one system to try to get access to the other by injecting itself somewhere in the boot chain. but that's a rare case..

@leip4Ier I think it's more of preventing transient kernel exploits from gaining persistence, including cross-OS-reinstall persistence

@leip4Ier secureboot in default config won't prevent evil mainds anyway - they can always boot Windows installer or sth.
You'd need to password-protect UEFI settings, and either remove boot entries and hope the maid can't pull out the HDD, or remove MS keys and instalm your own.

Sign in to participate in the conversation
Infosec Exchange

A Mastodon instance for info/cyber security-minded people.