In einem am Dienstag von Microsoft veröffentlichten Update für das Betriebssystem Windows 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 liegt in einem Fix, der darauf abzielt, eine alte Schwachstelle (CVE-2022-2601) im GRUB-Bootloader zu beseitigen, die 2022 behoben wurde. Microsoft hat bisher keine Stellungnahme zu dem Vorfall veröffentlicht und auch keinen Kommentar dazu abgegeben.
In der Änderungsnotiz wurde darauf hingewiesen, dass die Korrektur, die die Einführung der neuen SBAT-Politik (UEFI Secure Boot Advanced Targeting) vorsieht, für Systeme angewendet wird, auf denen ausschließlich Windows verwendet wird, und keine Konfigurationen mit Dual-Boot betreffen wird (die Änderung hatte die Verwendung von Boot-Images mit dem alten GRUB zum Umgehen des Secure Boot auf Systemen, auf denen nur Windows installiert ist, blockiert). Außerdem wurde darauf hingewiesen, dass die Änderungen zu Problemen beim Booten von ISO-Images älterer Systeme führen könnten, die mit einer verwundbaren Version von GRUB geliefert werden. Tatsächlich traten die Probleme auch bei Benutzern von Dual-Boot-Systemen auf, die neue Linux-Distributionen wie Ubuntu 24.04 und Debian 12.6 verwenden, in denen die GRUB-Sicherheitsanfälligkeit bereits lange behoben ist.
Das Problem tritt auf, wenn der Ladeprozess stoppt und die Meldung «Verifying shim SBAT data failed: Security Policy Violation. Something has gone seriously wrong: SBAT self-check failed: Security Policy Violation» angezeigt wird. Um das System wiederherzustellen, wird empfohlen, die im UEFI gespeicherten SBAT-Daten zu löschen. Dazu kann Secure Boot im BIOS deaktiviert werden, dann sollte ein aktuelles Linux-Distribution mit UEFI Secure Boot-Unterstützung, wie beispielsweise Ubuntu, geladen werden. Führen Sie in der Konsole den Befehl «mokutil —set-sbat-policy delete» aus und starten Sie anschließend die Linux-Distribution neu, um die korrekte SBAT-Policy zu installieren. Danach kann der Secure Boot-Modus im BIOS wieder 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 digitale Signaturen zurückzuziehen. SBAT beinhaltet die Hinzufügung von Metadaten zu den ausführbaren Dateien von UEFI-Komponenten, die Informationen über Hersteller, Produkt, Komponente und Version enthalten. Diese Metadaten werden digital signiert und können separat in die Listen der erlaubten oder verbotenen Komponenten für das UEFI Secure Boot aufgenommen werden. SBAT ermöglicht es, die Verwendung digitaler Signaturen für bestimmte Versionsnummern von Komponenten zu blockieren, ohne dass Schlüssel für Secure Boot zurückgezogen werden müssen.
Die Blockierung von Schwachstellen durch SBAT erfordert keine Verwendung der CRL-Liste von UEFI (dbx) und erfolgt auf der Ebene des internen Schlüsselwechsels zur Erstellung von Signaturen und Aktualisierungen von GRUB2, shim und anderen gebündelten Bootartefakten. Vor der Einführung von SBAT war die Aktualisierung der Liste abgelehnter Zertifikate (dbx, UEFI Revocation List) eine zwingende Voraussetzung für die vollständige Blockierung der Schwachstelle, da ein Angreifer, unabhängig vom verwendeten Betriebssystem, ein bootfähiges Medium mit einer älteren, anfälligen Version von GRUB2, die durch eine digitale Signatur beglaubigt ist, verwenden konnte.
Quelle: opennet.ru
