jsetje
commented
2 months ago I posted this issue under the shim repo since more folks are likely to see it here. I expect this to mostly be implemented in https://github.com/rhboot/certwrapper unless I find a bug with the revocation.efi support in shim.
Additional information on the bootmgr SKU Si revocation mechanism can be found here: https://support.microsoft.com/en-us/topic/kb5027455-guidance-for-blocking-vulnerable-windows-boot-managers-522bb851-0a61-44ad-aa94-ad11119c5e91 As of 15.8 shim does have support to apply those revocations as "latest".
hughsie
Problem:
Revocations beyond dbx require updating non-authenticated boot services variables. Unlike the signed dbx blobs that can be applied at runtime independently from updating the first stage bootloader, these revocations were initially built into shim as an optional “latest” and automatic payload. These payloads exist for both SBAT (shim based Linux distros) and SKU Si (bootmgr based Windows distros). Binaries from both ecosystems can be used to attack both ecosystems on typical systems that trust both the UEFI and Window CA.
While automatically putting a system into the most secure state possible by applying the latest revocation quickly is desirable, it carries a very real risk of preventing a legitimately installed system from booting. These scenarios are fall-back after and update and dual boot. While shim now supports picking up the revocation payload from a separate binary blob that can be updated independently from shim, the policy for deploying this blob will depend on how a particular system is being managed, similar to how dbx updates are being deployed.
Current state:
Most Linux distros are able to deliver a built-in automatic SBAT revocation that revokes binaries that are roughly 1 year old or older. Ones that are not have shifted to an empty automatic SBAT payload. All Linux distros deliver a shim that allows an opt-in SKU Si revocation to be applied, none of them do this automatically.
Windows currently only applies SKU Si revocations based on a manual opt-in and does not deliver SBAT revocations.
Proposal:
Systems should automatically apply the most recent payload for the ecosystem they are not in, unless the other binary is seen as an active bootloader before the one being booted on the boot list. (XXX: This seems awfully complex to protect dual boot systems that already have terrible compatibility. - Still this should be handled the same way by shim and bootmgr)
Systems that potentially need to support falling back to an older version of the same OS will need to manage revocations either manually or as part of an automated orchestration that drives the update / fallback process above the OS instance.
Solution:
Deliver revocations in a separate package that has dependencies that prevent it from being installed on an OS that it would revoke. This package also delivers previous revocations in cumulative blobs. Which revocation is put in place for shim to install can be configured as:
1) Apply the most recent revocation that does not revoke the OS being updated to.
2) Apply the most recent revocation that does not revoke the OS being updated from.
3) Apply the most recent revocation that does not revoke the OS installed at an alternate, supplied, mount location.
4) Manually lock revocations at a specific level.
Defaulting to (2) where (2) is effectively (1) for a fresh install.
Optional dual boot friendly packages:
Deliver an alternate stream of these packages that do not deliver SKU Si revocations for dual boot systems that an admin can opt into under the assumption that they are sometimes booting Windows and want Windows to manage its own revocations.
Rejected Proposal:
Record the hash of in-use bootloaders and add them to an SBAT specific exception list that allows only that binary to elude SBAT based revocation at the same time as applying the revocation.
Pros:
Cons:
Orthogonal concept:
Generic UEFI CA signed revocation.efi binaries could be delivered to fwupd and installed via that framework.