Much ado about SBAT

Eleven days ago, CVE-2023-32250 and CVE-2023-32254 were issued on bugs in the Linux kernel's ksmbd, an in-kernel SMB server. At the end of June, CVE-2023-3338 was issued on a bug in the DECNet implementation. Actively exploited, I don't know, but I'm sure there are.

I think for the most part people aren't interested in building exploits for these because Secure Boot attacks are pretty low value - especially because, at least as of last time I checked, there's a signed Ubuntu shim/GRUB which is happy to load arbitrary kernels. (I actually have a laptop running an old version of Debian with Ubuntu's signed shim/GRUB...) But it would be pretty easy to automate the process of turning root -> ring 0 escalations (which are much more common than non-root -> ring 0 escalations!) into bypasses of kernel_lockdown(7), if that would be interesting to anyone.

Specifically - I think this conversation would be more productive if you could define what exactly counts as an exploit that SBAT should protect against / that would merit bumping the SBAT generation number. My understanding of Secure Boot is there are two ways to think about this:

1) An attacker should not be able to produce a bootable system image using other people's signed kernels/bootloaders/shims/etc. that gets them arbitrary code execution in ring 0 before ExitBootServices() has been called.

2) An attacker should not be able to produce a bootable system image using other people's signed kernels/bootloaders/shims/etc. that gets them arbitrary code execution in ring 0 at any time.

The second one is what kernel_lockdown(7) is meant to protect against. But that's a more stringent policy than I think is really possible to achieve at least in the MS UEFI ecosystem. As mentioned, there are the Ubuntu shim/GRUB binaries, and also Windows itself hasn't been treating root -> ring 0 as a security issue (see e.g. http://www.github.com/ionescu007/r0ak which is a worked example of a driver allowing kernel read/write).

If the second definition is what you're actually trying to solve (and I might be out of date here and maybe the Ubuntu shims are now revoked?), it would be worth clearly documenting that, and then people can start producing those exploits. The ksmbd vulnerability mentioned in a sibling comment could quite easily be weaponized. But also a whole lot of other things that have the benefit of starting from a privileged position, like root in the initramfs, are interesting too.

If you're going for the first definition, I think it's worth documenting that too, because there's relatively code that runs before ExitBootServices() - there is some attacker-controlled stuff (command line parsing, initrd loading but not mounting), so an exploit isn't out of the question, but there's very little of it. And that might help the kernel folks get more comfortable with the idea of maintaining a generation number.

Or maybe you're going for some other definition which is not obvious to someone who does pay attention to Secure Boot, which means it'll be even less obvious to the average LKML reviewer.

(Or maybe the practical threat model here is that you want to make sure that attackers can't run code even in ring 3 as root, which means you can't trust the MS UEFI ecosystem and you have to sign all your own kernels/UKIs with your own key that you enroll yourself in DB and KEK... at which point you want to maintain the SBAT generation on your own and not trust anyone else to do it!)

To be clear - I am absolutely on board with criticizing the LKML crowd's refusal acknowledge what sort of bugs are security bugs and treatment of e.g. adding support for a new PlayStation controller's buttons as an "All users must upgrade." stable release that datacenter sysadmins need to care about just as much as they care about remote code execution in kernelspace. But I think that not clearly defining the security goals of SBAT / Secure Boot and saying you're only interested in vulnerabilities with known exploits risks making essentially the same mistake. It's silly to say that a vulnerability with a PoC that gets arbitrary code execution doesn't matter to you because nobody has constructed an exploit against your particular use case: they clearly could, and the only people who benefit from the obscurity are black hat attackers. A bug doesn't become unexploitable by refusing to mention the CVE in the commit message; neither does a bug become unexploitable by pointing out that there are no public exploits.

Because everybody will know what the upstream product gen ID is