Secure Boot is utterly broken (for general purpose pcs at least) anyways. I can just take an old windows kernel and boot with a configuration that loads a driver with a known vulnerability (a certain gpu manufacturer might be a good place to look) and a script that use it to run kernel mode code that does whatever it wants.
Newer Windows kernels generally blacklists drivers with know vulns, but you can just use an older version, and practically speaking old windows kernels can't be blacklisted because then people's install media that they might have paid for would stop working.
You could also unenroll all vendor supplied signing keys and load it up with one that you keep in a HSM.
Yes, you are technically correct that any opportunistic encryption scheme can be bypassed but it adds cost to the attack and (more importantly) it is a step towards a more secure system.
I feel like that is missing the point. You need social engineering (and probably not an easy case) to get people to change the keys. Using a pre-made image that allows you to bypass secure boot by way of a windows driver with a known vuln is practically free as soon as anyone packages it. I don't know whether that is currently being done, but I suspect it since I have seen people discussing bypassing PatchGuard in Windows 10 where they used a known exploit in a driver from a company that starts with n and ends with vidia.
I think I set this up in about 5 minutes on my devuan laptop (basically just Debian 8.3 for the purposes of this discussion). I told it to delete all its keys, then whitelisted the debian efi blob (no Microsoft signature needed), and all was well.
I did not test the configuration with an old copy of windows, but I'm pretty sure installing secure-boot enabled Linux distros now fails as expected.
Is this not standard functionality for secureboot laptops?
I remember hearing that there is some problem unenrolling vendor keys, especially MS ones, because they are also used to sign some of the firmware blobs. I'm not sure if that concern really became realized at any point, do you have any information regarding that?
I think it is bit more complicated than that. I checked some presentations [1] about UEFI/SB, and they do seem to imply that there is potentially some blobs (namely option roms, uefi applications and dxe drivers) that need to pass signature check. I don't know how much such modularity is really used in real life, especially in the boot path, but I think the "best practice" recommendation is to keep dxe core small and have stuff as loadable drivers.
FWIW Secure Boot has its own blacklist, called the Revoked Signatures or Forbidden Signatures database or dbx, though I don't know if and how it is actually used.
> old windows kernels can't be blacklisted because then people's install media that they might have paid for would stop working.
I understand the theory, but are you sure that is true in practice? There also could be a workaround (such as disabling Secure Boot for the install).
There was the secure golden key boot exploit last year[0]. In the conclusion they also points out that Microsoft can't revoke the affected bootmgr versions:
> Either way, it'd be impossible in practise for MS to revoke every bootmgr
earlier than a certain point, as they'd break install media, recovery partitions,
backups, etc.
Microsoft uses STLs, which are flashed into UEFI variables.
(had other glaring issues though, Secure Boot policies weren't checked with DBX or the STLs... which made it a real issue)
> Secure Boot is utterly broken (for general purpose pcs at least) anyways. I can just take an old windows kernel and boot with a configuration that loads a driver with a known vulnerability (a certain gpu manufacturer might be a good place to look) and a script that use it to run kernel mode code that does whatever it wants.
If you are referring to the Golden Key exploit (a misnomer because it doesn't involve keys, FWIW), it doesn't impact desktops and laptops, possibly because you can simply disable Secure Boot on them, but does affect certain mobile devices on which Secure Boot was supposed to be impossible to disable. It also requires physical access.
Newer Windows kernels generally blacklists drivers with know vulns, but you can just use an older version, and practically speaking old windows kernels can't be blacklisted because then people's install media that they might have paid for would stop working.