Ein Fehler im Windows-Update hat das Booten von Linux bei Verwendung von UEFI Secure Boot blockiert

Im am Dienstag veröffentlichten Update von Microsoft für das Windows-Betriebssystem wurde ein Problem festgestellt, das das Booten von Linux-Systemen verhindert, die parallel zu Windows auf demselben Computer installiert sind. Die Ursache für die Probleme ist ein Fix, der darauf abzielt, eine alte Sicherheitsanfälligkeit (CVE-2022-2601) im GRUB-Bootloader zu beheben, die 2022 behoben wurde. Microsoft hat bisher keine Stellungnahme zu dem aufgetretenen Fehler veröffentlicht und ihn nicht kommentiert.

In der Änderungsnotiz wurde darauf hingewiesen, dass der Fix, der die Implementierung der neuen SBAT-Politik (UEFI Secure Boot Advanced Targeting) ermöglicht, nur für Systeme angewendet wird, auf denen ausschließlich Windows installiert ist, und keine Dual-Boot-Konfigurationen betrifft (die Änderung blockierte die Verwendung von Boot-Images mit dem alten GRUB, um Secure Boot auf Systemen zu umgehen, auf denen nur Windows installiert ist). Es wurde auch erwähnt, dass die Änderung zu Problemen beim Booten von ISO-Images älterer Systeme führen kann, die mit einer anfälligen Version von GRUB ausgeliefert werden. Tatsächlich traten Probleme auch bei Nutzern von Dual-Boot-Systemen auf, die neue Linux-Distributionen wie Ubuntu 24.04 und Debian 12.6 verwenden, in denen die Sicherheitsanfälligkeit in GRUB bereits lange behoben ist.

Das Problem äußert sich in einem Abbruch des Bootvorgangs mit der Fehlermeldung „Verifying shim SBAT data failed: Security Policy Violation. Something has gone seriously wrong: SBAT self-check failed: Security Policy Violation“. Um die Funktionalität wiederherzustellen, wird empfohlen, die in UEFI gespeicherten SBAT-Daten zu löschen, indem Secure Boot im Firmware-Setup deaktiviert wird, ein aktuelles Linux-Distribution mit Unterstützung für UEFI Secure Boot, wie Ubuntu, geladen wird und der Befehl „mokutil —set-sbat-policy delete“ in der Konsole ausgeführt wird. Danach sollte das Linux-Distribution neu gestartet werden, um die korrekte SBAT-Politik zu installieren. Anschließend kann der Secure Boot-Modus wieder in der Firmware aktiviert werden.

Der SBAT-Mechanismus wurde von Red Hat in Zusammenarbeit mit Microsoft entwickelt, um Schwachstellen im GRUB-Bootloader und der shim-Schicht zu blockieren, ohne die digitale Signatur zurückzuziehen. SBAT bedeutet, dass den ausführbaren Dateien von UEFI-Komponenten zusätzliche Metadaten hinzugefügt werden, die Informationen über den Hersteller, das Produkt, die Komponente und die Version enthalten. Die angegebenen Metadaten werden durch eine digitale Signatur beglaubigt und können separat in die Listen der genehmigten oder gesperrten Komponenten für UEFI Secure Boot aufgenommen werden. SBAT ermöglicht das Blockieren der Verwendung digitaler Signaturen für bestimmte Versionsnummern von Komponenten, ohne dass Schlüssel für Secure Boot zurückgezogen werden müssen.

Das Blockieren von Schwachstellen über SBAT erfordert keinen Einsatz der UEFI-Zertifikat-Widerrufsliste (dbx), sondern erfolgt auf der Ebene des Austauschs des internen Schlüssels zur Erstellung von Signaturen und zur Aktualisierung von GRUB2, shim und anderen von Distributionen gelieferten Boot-Artefakten. Vor der Implementierung von SBAT war die Aktualisierung der Widerrufsliste (dbx, UEFI Revocation List) eine zwingende Voraussetzung für die vollständige Blockierung einer Schwachstelle, da ein Angreifer, unabhängig vom verwendeten Betriebssystem, ein bootfähiges Medium mit einer alten anfälligen Version von GRUB2, die durch eine digitale Signatur beglaubigt war, zur Kompromittierung von UEFI Secure Boot verwenden konnte.

Quelle: opennet.ru