Much ado about SBAT

Posted Jul 20, 2023 16:55 UTC (Thu) by smurf (subscriber, #17840)
Parent article: Much ado about SBAT

The idea of "no single serial number can possibly work" has been around since the first distributed versioning system was invented, umpteen years ago.

Thus if I had to boil the kernel version down to a single integer, I'd use the number of minutes since 2023-07-01, or something along these lines.

Much ado about SBAT

Posted Jul 20, 2023 17:35 UTC (Thu) by NYKevin (subscriber, #129325) [Link] (9 responses)

A constantly-updating number would imply that every kernel gets revoked as soon as the next release happens (if not sooner). The folks running old, but supported kernels would probably not appreciate that.

Much ado about SBAT

Posted Jul 20, 2023 18:25 UTC (Thu) by excors (subscriber, #95769) [Link] (8 responses)

As far as I can tell, installing a new kernel would not automatically revoke older generations - revocations are applied by the system administrator (like https://support.microsoft.com/en-gb/topic/microsoft-guida...) or through Windows Update etc. (This differs from other anti-rollback mechanisms which simply refuse to install or boot an update if its generation number is lower than the one previously installed, like https://android.googlesource.com/platform/external/avb/+/...)

I presume the process is that someone identifies a serious bug that can be used to undermine Secure Boot, they make sure it's fixed on all interesting branches, they mark the current point in time, they get everyone who signs kernels to promise they're never going to sign any kernel without that bug fix, then they ask Microsoft to revoke all versions before that point. In that case, I don't think it makes a fundamental difference whether the point is identified by e.g. last CommitDate in minutes since epoch, or by a global generation number that was incremented at the same time as the bug was fixed on all branches. The latter just means the coordination between all the parties is recorded in the kernel repository, whereas the former means the kernel developers don't have any involvement and the coordination happens in some less-visible external forum and there's more chance of mistakes.

Much ado about SBAT

Posted Jul 20, 2023 19:41 UTC (Thu) by smurf (subscriber, #17840) [Link] (7 responses)

On the other hand, with a time-based scheme you can simply say "you can't boot kernels older than a month" and be done with it, no process required, formal or otherwise.

Also, my impression is that many of those fixes are applied more-or-less silently, so nobody is going to start a formal process that points a big fat red arrow at a particular hole.

Also², what happens when two of these formal processes run in parallel, or the resolution of one of them overtakes the other? Resolving these questions, plus then running the formal process itself whenever that's required (who decides?), is going to cost a nontrivial amount of work time = money.

Much ado about SBAT

Posted Jul 20, 2023 20:32 UTC (Thu) by bluca (subscriber, #118303) [Link] (3 responses)

That is obviously not really feasible. The timestamp is irrelevant, what matters is whether there is an observed vulnerability or not.

Much ado about SBAT

Posted Jul 21, 2023 6:05 UTC (Fri) by smurf (subscriber, #17840) [Link] (2 responses)

Of course it's feasible. Grab the top commit's timestamp, convert to minutes, add to SBAT record, compile, install, boot, verify it's working, tell your boot loader not to allow booting any kernels with a lower number. Done.

The question is whether you can reliably capture all relevant security violations with that. Well, no you can't, not reliably. I know that. The point is that there does not seem to be a way to reliably increment the number every time a problem is found *and* make sure that all those fixes are back- and crossported (otherwise the increment won't mean anything) *and* not point big fat red arrows at security problems, which would happen if the same commit increments the number in the SBAT. (And if it doesn't you wouldn't know what to backport in order to keep the guarantee.)

So if there's a choice between a zero-precent solution (not do the SBAT thing at all), a 100% solution that is costly and nobody is going to implement, and a 95% solution that doesn't really cost anything, I advocate for the latter.

Much ado about SBAT

Posted Jul 21, 2023 9:16 UTC (Fri) by bluca (subscriber, #118303) [Link] (1 responses)

No, it is not sensible, because the revocation would have to be incremented and deployed every month for no reason at all, which is just silly busywork. The stable backport issue is a made up strawman - it doesn't matter from which branch or which version number it has, either it's vulnerable to the identified issue or it isn't. If it's vulnerable it stops booting until fixed and bumped, it's as simple as that.

Much ado about SBAT

Posted Jul 23, 2023 21:03 UTC (Sun) by danielthompson (subscriber, #97243) [Link]

Where does the busy work come from?

"the revocation would have to be incremented" means updating the minimum accepted generation number (revoking everything older than *this* number), right? If so, there is no good reason to update the minimum accepted generation number simply because an upstream component increases a time-based generation number.

Much ado about SBAT

Posted Jul 22, 2023 3:27 UTC (Sat) by NYKevin (subscriber, #129325) [Link] (2 responses)

To my understanding, no, you can't do that. Or at least, you can't do that, assuming that I'm understanding your proposal correctly:

1. Revoke all old kernels, scoped to some organization, so the IT department can just tell everyone "you have to use the latest release, no exceptions." This is what I think you are proposing, and it makes logical sense.
2. Revoke all old kernels, globally, and everyone using SBAT enforcement is forced to comply. This is how the technology is meant to be used (at least as far as I can tell), and it is ridiculous, so presumably not what you meant.

In short, these version numbers are not (apparently) intended for enforcing generic IT policies, and you cannot just "roll your own" SBAT policy (at least as far as I have been able to determine). They are intended as a more efficient means of global certificate/signature revocation, and are inherently unscoped. See https://github.com/rhboot/shim/blob/main/SBAT.md for more discussion of motivations etc.

Much ado about SBAT

Posted Jul 22, 2023 3:32 UTC (Sat) by NYKevin (subscriber, #129325) [Link] (1 responses)

> and you cannot just "roll your own" SBAT policy (at least as far as I have been able to determine).

To be more explicit: I believe that this is impossible, because I believe that your SBAT policy would have to be signed by one of the keys that your firmware trusts, and the keys that your firmware trusts are the same as the keys that everybody else's firmware trusts, so if you could just make up and sign an arbitrary policy, you could trivially bypass the whole scheme.

Much ado about SBAT

Posted Jul 22, 2023 6:10 UTC (Sat) by mjg59 (subscriber, #23239) [Link]

It's absolutely possible for enterprises to enroll their own keys (and to have their own keys enrolled at the VAR step of device provisioning), and any such enterprise could impose their own policy.

Much ado about SBAT

Posted Jul 20, 2023 20:00 UTC (Thu) by flussence (guest, #85566) [Link] (4 responses)

A Modest Proposal: simply grep the entire kernel and git log at build time for strings of the form "CVE-(\d+)-(\d+)", numify them ($0 * 100000 + $1), and use the maximum.

Much ado about SBAT

Posted Jul 20, 2023 20:12 UTC (Thu) by geofft (subscriber, #59789) [Link] (3 responses)

That would work a lot better if the kernel did not have an unwritten policy of deliberately not mentioning CVEs or exploitability in commit messages.

See, for instance, the commit message fixing StackRot, a vulnerability so significant it got a cutesy name and not just a CVE: https://git.kernel.org/linus/9471f1f2f502

Much ado about SBAT

Posted Jul 20, 2023 21:46 UTC (Thu) by rahulsundaram (subscriber, #21946) [Link] (1 responses)

> That would work a lot better if the kernel did not have an unwritten policy of deliberately not mentioning CVEs or exploitability in commit messages.

Yes, this remains a troublesome approach. A lot of other security efforts in the kernel have improved including the reception of hardening patches and maybe Rust will help in the future. Hopefully at some point they stop actively hiding it when they are aware of the issue ahead of time.

Much ado about SBAT

Posted Jul 20, 2023 23:43 UTC (Thu) by bluca (subscriber, #118303) [Link]

It's downright irresponsible, and gives bad actors a head start.

Much ado about SBAT

Posted Jul 21, 2023 0:46 UTC (Fri) by willy (subscriber, #9762) [Link]

The decision about whether to name a vulnerability is the security researcher's decision, and does not reflect a finding of significance (who would have the authority to make such a finding, anyway?)