Re: The Achilles Heel Of Secure Boot: Certificate Revocation

Lawrence D’Oliveiro <[email protected]> writes:
> Some years ago, there was a report about a compromised boot image from
> Kaspersky labs; Microsoft initially issued a revocation of its Secure
> Boot Certificate, but then had to withdraw that because it caused so
> many problems for Windows users who couldn’t (or just wouldn’t)
> upgrade/replace the affected versions of Kaspersky products
> <https://arstechnica.com/information-technology/2020/07/new-flaw-neuters-secure-boot-but-theres-no-reason-to-panic-heres-why/>.
>
> Now it turns out Microsoft has been negligent in revoking other
> certificates for ancient, compromised, obsolete bootloader “shims”
> <https://arstechnica.com/security/2026/07/microsoft-secure-boot-has-been-broken-for-most-of-its-existence/>
> -- even when the repercussions of doing so would be minor, there still
> didn’t seem to be the will to promptly enforce the rules that the
> company itself created.

The surface problem here seems to be a process error somewhere between
the identification of a vulnerability and revocation of the impacted
code. Where it went wrong is not clear but for the vulnerability they
quote the issue was identified in 2016[1] but I can’t find any evidence
that an advisory was issued, and the lack of a CVE until 2026 is rather
suggestive - it could be that the vulnerability was never communicated
beyond the commit message. As such I’d be cautious about assigning
negligence to the CA, at least on the evidence available.

   [1] https://github.com/rhboot/shim/commit/d241bbbdb

> Certificate revocation in the event of a security compromise is also a
> measure used in another context: with TLS/SSL certificates for
> securely accessing websites. In this situation, it has long been known
> to be a troublesome and unreliable mechanism. And so something called
> “OCSP” was invented as a kind of workaround, only to fall victim to
> its own problems.
>
> Which is why, in the TLS/SSL world, the general consensus is that the
> only reliable solution nowadays is to drastically shorten the validity
> interval of the certificates -- some are suggesting they should be
> valid for no longer than a week -- so the problem is (mostly) solved
> simply by reducing the opportunity for malicious parties to make use
> of compromised certificates.
>
> This solution doesn’t seem practical for Secure Boot keys, which have
> to be stored in UEFI flash RAM on every PC ... or could something like
> it be made to work?

The issue here is about revoking UEFI executables, not revoking keys, as
in TLS.

Our approach (in a non-EFI context) has generally involved restricting
downgrades: effectively, everything that is too old is automatically
revoked, once you upgrade past a certain point. But we’re the only
legitimate source of upgrade images for our products, whereas PCs are
open platforms, with software supplied by anyone and everyone, making it
a much harder problem to address, because there are multiple legitimate
sources of code. The proliferation of components is also a problem: the
firmware executes Shim, which executes Grub2, which loads the Linux
kernel and initramfs, which mounts the root filesystem and executes
init. Every one of those components can contain vulnerabilities.

In contrast I’m aware of platforms where the firmware directly verifies
and loads a kernel and base OS image; they have no intermediate shims or
boot loaders to contain vulnerabilities at all. Much easier to secure,
but it doesn’t make for an easily ‘tinkerable’ platform.

-- 
https://www.greenend.org.uk/rjk/