Much ado about SBAT

Posted Jul 21, 2023 11:02 UTC (Fri) by bluca (subscriber, #118303)
In reply to: Much ado about SBAT by pbonzini
Parent article: Much ado about SBAT

> Secure Boot purports to only let you run signed code.
> Ergo, any kernel execution bug is a secure boot bypass.

Most definitely not, it's not a code integrity mechanism. There only a few real use cases of full code integrity deployed using Linux that I am aware of, and none of them even use UEFI.

> The idea that it has to be "actively exploited" only makes it clear that it's security theater.

Yep, 'boothole' and 'blacklotus' are definitely just 'theater', nothing to worry about

Much ado about SBAT

Posted Jul 21, 2023 13:11 UTC (Fri) by pbonzini (subscriber, #60935) [Link]

I don't know, if I want to write a rootkit I'll probably exploit a random vulnerability rather than try and thwart the signing. So if revocations are restricted to the latter, it will be security theater. That's my point. Maybe for bootloaders it's good enough, but not for something that receives as much untrusted code and data as a general purpose OS.

> Yep, 'boothole' and 'blacklotus' are definitely just 'theater', nothing to worry about

It's exactly because they're worrisome, that the SBAT number should be bumped for any vulnerability, no matter if actively exploited ot not.

Much ado about SBAT

Posted Jul 22, 2023 0:53 UTC (Sat) by geofft (subscriber, #59789) [Link] (5 responses)

> Yep, 'boothole' and 'blacklotus' are definitely just 'theater', nothing to worry about

I would, in fact, argue that anyone who cares about responding to boothole and batondrop but not ordinary privilege escalation vulnerabilities is performing security theater! What actual use cases consider either of these a danger that should not consider local privilege escalation a danger?

If your goal is to protect against in-the-wild exploits and not vulnerabilities (which lines up with mentioning blacklotus the exploit not batondrop the vulnerability), that's maybe reasonable - but you can't do that with SBAT, because whether an exploit exists isn't a property of the binary being executed, it's a property of the rest of the world. That's why everyone's asking about vulnerabilities, because those are a property of the binary being executed. If an exploit gets developed today for a bug in kernel 5.0 that's fixed in kernel 5.1, you can't go back in time and make the SBAT data of 5.0 and 5.1 different.

And there is already a mechanism for handling this, namely DBX. If that gets out of hand, then the only thing you can really do is to label every kernel version with some different metadata and have a mechanism for telling the firmware what the last unexploited kernel version is, which is a thing that not only has been proposed a few times in response to this proposal but is actually implemented in the real world for Chromebooks.

Much ado about SBAT

Posted Jul 22, 2023 1:40 UTC (Sat) by mjg59 (subscriber, #23239) [Link] (3 responses)

One of the distinctions is ease of identification - the earlier in the boot chain you can compromise trust, the less obvious it's going to be to a user. It also increases your ability to subvert aspects of measured boot (although black lotus failed to do this, even though technically possible), and so I'd argue that there is a greater risk. I've got a bunch of thoughts here that I'll try to write up.

dbx is a limited resource, and flagging every single individual image as revoked isn't viable - the easy solution is to force everyone to migrate to new kernel signing keys and then revoke all the old shims, but even that's a lot of entries. So having a centralised way to say "We believe that kernels with this property should be considered insecure in this particular fashion" and then have agents that can be trusted to enforce that policy is extremely useful from a maintainability perspective, but I also take your point that in the current porposal a vulnerability that was fixed (perhaps inadvertently) between 6.0 and 6.1 and is then later actively exploited in 6.0 is going to mean either point releases for 6.1 for no reason other than bumping SBAT or revoking kernels that don't have the vulnerability. The goal of the "single number" approach is, to my understanding, largely to make it easier for vendors to make assertions that they're shipping backports that fix the vulnerability, but maybe there's another approach that doesn't require this. I'll think about it some.

Much ado about SBAT

Posted Jul 22, 2023 2:14 UTC (Sat) by geofft (subscriber, #59789) [Link] (2 responses)

The 2009 "Security impact ratings considered harmful" paper which I very slightly coauthored https://www.usenix.org/legacy/event/hotos09/tech/full_pap... has a little bit of an analysis of how long it takes between the commit fixing a bug and the assignment of a CVE. There is a sizable long tail of CVE assignment well after the bug fix - the paper reports 14% of vulnerabilities had more than eight weeks of "impact delay", and you can see on the graph several vulnerabilities with a year or more of impact delay. So I think it will not be unusual to discover that an issue fixed in a released kernel had security impact. (After all, security bugs are just normal bugs....)

It'd be interesting to see this data for newer kernel versions.

Re ease of identification - the thing I'm imagining isn't (just) attacking the user's running OS, it's setting up a bootkit that boots a normal Linux kernel with literally any lockdown-integrity vulnerability (i.e. any kernel code execution bug, even if only exploitable by root) with a tiny initrd that immediately exploits it, does whatever nefarious thing it wants to do, and chainloads the real OS. It's true that this is likely to break measured boot, but I think it's basically as undiscoverable as any other bootkit: kernels boot pretty fast when you're not interested in hardware or userspace.

Much ado about SBAT

Posted Jul 22, 2023 2:24 UTC (Sat) by mjg59 (subscriber, #23239) [Link] (1 responses)

kexec doesn't hand over enough state to make it easy to perform a seamless handoff of (eg) graphics, so you'd need to jump through some hoops to avoid graphical artifacts or interruption of the boot splash in the process. I agree that how obvious this is is going to vary. But as we move towards initramfs being part of the signed payload, the initramfs→kexec approach becomes harder and you need to actually leave additional filesystem artifacts around.

Much ado about SBAT

Posted Aug 3, 2023 23:15 UTC (Thu) by Kamilion (subscriber, #42576) [Link]

... I get graphical corruption of plymouth and knocked out of graphical boot to read two or three `quiet`-unsuppressed kernel warning messages already.

RETBleed: WARNING: Spectre V2 mitigation leaves CPU vulnerable to RETBleed attacks, data leaks possible!
[drm:vmw_host_printf [vmwgfx]] *ERROR* Failed to send host log message.
systemd[1]: Invalid DMI field header.

I don't get the vmwgfx error outside of virtualbox, obviously.
(And this is a Skylake Xeon-Scalable Gold!)

I don't think I have a single system that can boot from firmware to desktop *without* plymouth choking somewhere. My ryzens exhibit similar but not identical "unsuppressed messages breaking graphical boot while `quiet` is asserted" issues.

I honestly got so sick of it I dropped `quiet` and defaulted my ubuntu spin to `verbose`.

Much ado about SBAT

Posted Jul 22, 2023 7:52 UTC (Sat) by smurf (subscriber, #17840) [Link]

> If an exploit gets developed today for a bug in kernel 5.0 that's fixed in kernel 5.1, you can't go back in time and make the SBAT data of 5.0 and 5.1 different

except when the SBAT number is time- or release-based and thus incremented as a matter of fact.