mjg59 | What the fuck is an SBAT and why does everyone suddenly care

Skip to Main Content

Entry tags:

advogato,
fedora

What the fuck is an SBAT and why does everyone suddenly care

Short version: Secure Boot Advanced Targeting and if that's enough for you you can skip the rest you're welcome.

Long version: When UEFI Secure Boot was specified, everyone involved was, well, a touch naive. The basic security model of Secure Boot is that all the code that ends up running in a kernel-level privileged environment should be validated before execution - the firmware verifies the bootloader, the bootloader verifies the kernel, the kernel verifies any additional runtime loaded kernel code, and now we have a trusted environment to impose any other security policy we want. Obviously people might screw up, but the spec included a way to revoke any signed components that turned out not to be trustworthy: simply add the hash of the untrustworthy code to a variable, and then refuse to load anything with that hash even if it's signed with a trusted key.

Unfortunately, as it turns out, scale. Every Linux distribution that works in the Secure Boot ecosystem generates their own bootloader binaries, and each of them has a different hash. If there's a vulnerability identified in the source code for said bootloader, there's a large number of different binaries that need to be revoked. And, well, the storage available to store the variable containing all these hashes is limited. There's simply not enough space to add a new set of hashes every time it turns out that grub (a bootloader initially written for a simpler time when there was no boot security and which has several separate image parsers and also a font parser and look you know where this is going) has another mechanism for a hostile actor to cause it to execute arbitrary code, so another solution was needed.

And that solution is SBAT. The general concept behind SBAT is pretty straightforward. Every important component in the boot chain declares a security generation that's incorporated into the signed binary. When a vulnerability is identified and fixed, that generation is incremented. An update can then be pushed that defines a minimum generation - boot components will look at the next item in the chain, compare its name and generation number to the ones stored in a firmware variable, and decide whether or not to execute it based on that. Instead of having to revoke a large number of individual hashes, it becomes possible to push one update that simply says "Any version of grub with a security generation below this number is considered untrustworthy".

So why is this suddenly relevant? SBAT was developed collaboratively between the Linux community and Microsoft, and Microsoft chose to push a Windows update that told systems not to trust versions of grub with a security generation below a certain level. This was because those versions of grub had genuine security vulnerabilities that would allow an attacker to compromise the Windows secure boot chain, and we've seen real world examples of malware wanting to do that (Black Lotus did so using a vulnerability in the Windows bootloader, but a vulnerability in grub would be just as viable for this). Viewed purely from a security perspective, this was a legitimate thing to want to do.

(An aside: the "Something has gone seriously wrong" message that's associated with people having a bad time as a result of this update? That's a message from shim, not any Microsoft code. Shim pays attention to SBAT updates in order to avoid violating the security assumptions made by other bootloaders on the system, so even though it was Microsoft that pushed the SBAT update, it's the Linux bootloader that refuses to run old versions of grub as a result. This is absolutely working as intended)

The problem we've ended up in is that several Linux distributions had not shipped versions of grub with a newer security generation, and so those versions of grub are assumed to be insecure (it's worth noting that grub is signed by individual distributions, not Microsoft, so there's no externally introduced lag here). Microsoft's stated intention was that Windows Update would only apply the SBAT update to systems that were Windows-only, and any dual-boot setups would instead be left vulnerable to attack until the installed distro updated its grub and shipped an SBAT update itself. Unfortunately, as is now obvious, that didn't work as intended and at least some dual-boot setups applied the update and that distribution's Shim refused to boot that distribution's grub.

What's the summary? Microsoft (understandably) didn't want it to be possible to attack Windows by using a vulnerable version of grub that could be tricked into executing arbitrary code and then introduce a bootkit into the Windows kernel during boot. Microsoft did this by pushing a Windows Update that updated the SBAT variable to indicate that known-vulnerable versions of grub shouldn't be allowed to boot on those systems. The distribution-provided Shim first-stage bootloader read this variable, read the SBAT section from the installed copy of grub, realised these conflicted, and refused to boot grub with the "Something has gone seriously wrong" message. This update was not supposed to apply to dual-boot systems, but did anyway. Basically:

1) Microsoft applied an update to systems where that update shouldn't have been applied
2) Some Linux distros failed to update their grub code and SBAT security generation when exploitable security vulnerabilities were identified in grub

The outcome is that some people can't boot their systems. I think there's plenty of blame here. Microsoft should have done more testing to ensure that dual-boot setups could be identified accurately. But also distributions shipping signed bootloaders should make sure that they're updating those and updating the security generation to match, because otherwise they're shipping a vector that can be used to attack other operating systems and that's kind of a violation of the social contract around all of this.

It's unfortunate that the victims here are largely end users faced with a system that suddenly refuses to boot the OS they want to boot. That should never happen. I don't think asking arbitrary end users whether they want secure boot updates is likely to result in good outcomes, and while I vaguely tend towards UEFI Secure Boot not being something that benefits most end users it's also a thing you really don't want to discover you want after the fact so I have sympathy for it being default on, so I do sympathise with Microsoft's choices here, other than the failed attempt to avoid the update on dual boot systems.

Anyway. I was extremely involved in the implementation of this for Linux back in 2012 and wrote the first prototype of Shim (which is now a massively better bootloader maintained by a wider set of people and that I haven't touched in years), so if you want to blame an individual please do feel free to blame me. This is something that shouldn't have happened, and unless you're either Microsoft or a Linux distribution it's not your fault. I'm sorry.

Threaded | Flat

That bit me when doing the install for my current machine which came with Windows on it - the Ubuntu LTS didn't have the correct fix applied (or at least the SBAT didn't recognise it), so I had to install a .10 Ubuntu which the SBAT was happy with. At least though this was something that happened during build, and not something that's broken a running dual-boot machine.

Maybe a better way of handling this would have been to have two updates instead of one:

Update 1: Change SBAT policy to "warn". Then ask the user to press a key to continue if the security generation isn't matching the policy. This allows users to continue using their software and report this to the vendor and update etc.

Update 2: Change SBAT policy to "enforce".

And instead of having SBAT define a single minimal security generation it could have two levels, one for warning and one for enforcing.

Fantastic summary, thank you.

Is there any way that an admin could express the following policy?

> All shims, including future versions, should be treated as malware and should not be allowed to boot.

In other words, what to write in SBAT, how to sign?

How does this affect installation media? Does this mean the bootloader on the Windows installation disk is now untrusted? Or just grub?

Started with Linux and renounced Windon't in 2006 and never looked back.
If you need Wince so bad use a separate machine and SMD / samba /email /ftp /usb disk files from one to another. PC hardware is cheap. My 10 year old $125 used Dell performs better than my Wife's 1 year old Win11 machine. Why cripple yourself with Dual boot?

Could this be handled by remembering what's the latest generation that successfully booted and refusing to boot anything older?

And why is it that it's a Windows update that makes Linux unbootable, why not a Linux update that makes Windows unbootable ? Does it mean that Microsoft decides what's good or bad for YOUR computer ? What rights do they have on my computer ? They should take care of their own system, not my computer.

And if anyone thinks this improves security, then they mean that a computer without windows is insecure since it will not receive such hardware updates, which is totally ridiculous of course!

Last, what does it take to distribute such updates which declare all existing versions as untrustworthy so that all UEFI-based computers in the world are left unbootable ?

I'd just set up a new PC that came with Win11 home preinstalled and I'd setup Ubuntu 24.04 to dual boot. I ran the MS Windows Update when it was released and had no problems as I would have expected with the latest Ubuntu (OK Ubuntu 24.04 has a few minor issues still). I've read a few articles on this problem and this is the first one that has explained the issue in detail - I wanted to know why I'd avoided the issue.

Ah, I wonder if this is why one PC of mine suddenly started to stop booting recently.

Well, a couple things are strange there. Many people with the most recent versions, just installed linux distros had problems some solved bring Back olders versions (mint distro).i had problems myself with a very thé most recent Debian version just installed. One may says thats the distro faults. The grub was updated. But i could still accept that explanation if someone tells me how the grub files (at least one of them) where updated same exactly same time that windows were updating. I have managed to enter at grub menu and the last change on its files were same day and time windows were updating, right after i tried to turn the computer off. For the next days i used only windows and grub was still working. Then there was another Windows update and after that one, i received that scary msg that something was terribly wrong and the computer was unable to boot. What a hell had happen?

It seems that now also linux distributions have started causing this. Just booting a linux live cd will update the sbat and break secure booted systems.

Threaded | Flat