{"id":119554,"date":"2024-08-21T09:43:00","date_gmt":"2024-08-21T07:43:00","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/oshibka-v-obnovlenii-k-windows-blokirovala-zagruzku-linux-pri-ispolzovanii-uefi-secure-boot"},"modified":"2024-08-21T09:43:00","modified_gmt":"2024-08-21T07:43:00","slug":"oshibka-v-obnovlenii-k-windows-blokirovala-zagruzku-linux-pri-ispolzovanii-uefi-secure-boot","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/novosti-interneta\/oshibka-v-obnovlenii-k-windows-blokirovala-zagruzku-linux-pri-ispolzovanii-uefi-secure-boot","title":{"rendered":"Ein Fehler bei der Windows-Update hat den Boot von Linux mit aktiviertem UEFI Secure Boot blockiert","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
In einem am Dienstag von Microsoft ver\u00f6ffentlichten Update f\u00fcr 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\u00fcr 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\u00f6ffentlicht und auch keinen Kommentar dazu abgegeben. <\/p>\n
In der \u00c4nderungsnotiz wurde darauf hingewiesen, dass die Korrektur, die die Einf\u00fchrung der neuen SBAT-Politik (UEFI Secure Boot Advanced Targeting) vorsieht, f\u00fcr Systeme angewendet wird, auf denen ausschlie\u00dflich Windows verwendet wird, und keine Konfigurationen mit Dual-Boot betreffen wird (die \u00c4nderung 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\u00dferdem wurde darauf hingewiesen, dass die \u00c4nderungen zu Problemen beim Booten von ISO-Images \u00e4lterer Systeme f\u00fchren k\u00f6nnten, die mit einer verwundbaren Version von GRUB geliefert werden. Tats\u00e4chlich 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\u00e4lligkeit bereits lange behoben ist. <\/p>\n
Das Problem \u00e4u\u00dfert sich durch das Anhalten des Ladeprozesses mit der Meldung \u201eVerifying shim SBAT data failed: Security Policy Violation. Something has gone seriously wrong: SBAT self-check failed: Security Policy Violation\u201c. Um die Funktionalit\u00e4t wiederherzustellen, wird empfohlen, die im UEFI gespeicherten SBAT-Daten zu l\u00f6schen. Dazu kann Secure Boot im Firmware-Setup deaktiviert werden. Laden Sie dann ein aktuelles Linux-Distribution, das UEFI Secure Boot unterst\u00fctzt, wie Ubuntu, und f\u00fchren Sie im Terminal den Befehl \u201emokutil \u2014set-sbat-policy delete\u201c aus. Starten Sie danach die Linux-Distribution neu, um die korrekte SBAT-Policy zu installieren. Anschlie\u00dfend k\u00f6nnen Sie den Secure Boot-Modus in der Firmware wieder aktivieren. <\/p>\n
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\u00fcckzuziehen. SBAT beinhaltet die Hinzuf\u00fcgung von Metadaten zu den ausf\u00fchrbaren Dateien von UEFI-Komponenten, die Informationen \u00fcber Hersteller, Produkt, Komponente und Version enthalten. Diese Metadaten werden digital signiert und k\u00f6nnen separat in die Listen der erlaubten oder verbotenen Komponenten f\u00fcr das UEFI Secure Boot aufgenommen werden. SBAT erm\u00f6glicht es, die Verwendung digitaler Signaturen f\u00fcr bestimmte Versionsnummern von Komponenten zu blockieren, ohne dass Schl\u00fcssel f\u00fcr Secure Boot zur\u00fcckgezogen werden m\u00fcssen. <\/p>\n
Die Blockierung von Schwachstellen durch SBAT erfordert keine Verwendung der CRL-Liste von UEFI (dbx) und erfolgt auf der Ebene des internen Schl\u00fcsselwechsels zur Erstellung von Signaturen und Aktualisierungen von GRUB2, shim und anderen geb\u00fcndelten Bootartefakten. Vor der Einf\u00fchrung von SBAT war die Aktualisierung der Liste abgelehnter Zertifikate (dbx, UEFI Revocation List) eine zwingende Voraussetzung f\u00fcr die vollst\u00e4ndige Blockierung der Schwachstelle, da ein Angreifer, unabh\u00e4ngig vom verwendeten Betriebssystem, ein bootf\u00e4higes Medium mit einer \u00e4lteren, anf\u00e4lligen Version von GRUB2, die durch eine digitale Signatur beglaubigt ist, verwenden konnte. \n Quelle: opennet.ru<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"