alt Hacker NewsExploiting signed bootloaders to circumvent UEFI Secure Boot
Comments
(2019)
The biggest weakness of secure boot was always third-party vendors shipping "insecure" bootloaders. It's a lot of work to verify signatures for every bit of data that gets loaded, especially on the PC platform.
The security story of the PC platform is such a mess due to fragmentation. I have way more trust in Apple's security here.
> Most motherboards include only Microsoft keys as trusted
Is this really true, in 2019 when this was written or today? I haven’t seen a motherboard that didn’t let me enroll my own keys in a really long time. Laptops are a different story but even there, it’s been awhile.
> Microsoft forbid to sign software licensed under GPLv3 because of tivoization restriction license rule
Ah yes, GPLv3 is now Microsoft’s fault?
It's really funny to me that Microsoft's attempt to finally stamp out desktop Linux once and for all failed because one of Microsoft's antivirus vendor partners couldn't write secure software to save their lives.
The continued Linux desktop solely relies on antivirus vendors writing crappy insecure software. So we'll be fine forever.
Empowering the 'User' (hardware owner) should have always been the focus.
From that mindset what makes sense are hardware vendors including a cache of trusted third party root certificates from known other vendors. Today this would include Microsoft, the same said hardware vendor, probably various respected Linux organizations/groups (Offhand, Linux Foundation, ArchLinux, Debian, IBM/RedHat, Oracle, SUSE, etc), similar for BSD...
Crucially the end user should then be ASKED which to enable. None should be enrolled out of the box. They might also be enabled only for specific things. E.G. HW vendor could be enabled only for new system firmware signatures (load using the existing software) rather than generic UEFI boot targets. The user should also be able to enroll their own CA certs as well; multiple of them. Useful for Organization, Division Unit, and system local signatures.
It would also, really, be nice if UEFI mandated a uniform access API (maybe it does) for local blobs stored in non mass-storage space. This would be a great place to stash things like UEFI drivers for accessing additional types of hardware drivers, OS boot bits + small related files, etc. I would have said 1GB of storage would be more than sufficient for this - however Microsoft has proven that assumption incorrect. Still it'd be nice to have a standard place and a feature that says the system ships with this much reliable secondary storage included (or maybe 1-2 micro-SD card slots, etc).