{"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\/news\/oshibka-v-obnovlenii-k-windows-blokirovala-zagruzku-linux-pri-ispolzovanii-uefi-secure-boot","title":{"rendered":"Ein Fehler im Windows-Update hat das Booten von Linux bei Verwendung von UEFI Secure Boot blockiert","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Im am Dienstag ver\u00f6ffentlichten Update von Microsoft f\u00fcr 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\u00fcr die Probleme ist ein Fix, der darauf abzielt, eine alte Sicherheitsanf\u00e4lligkeit (CVE-2022-2601) im GRUB-Bootloader zu beheben, die 2022 behoben wurde. Microsoft hat bisher keine Stellungnahme zu dem aufgetretenen Fehler ver\u00f6ffentlicht und ihn nicht kommentiert. <\/p>\n
In der \u00c4nderungsnotiz wurde darauf hingewiesen, dass der Fix, der die Implementierung der neuen SBAT-Politik (UEFI Secure Boot Advanced Targeting) erm\u00f6glicht, nur f\u00fcr Systeme angewendet wird, auf denen ausschlie\u00dflich Windows installiert ist, und keine Dual-Boot-Konfigurationen betrifft (die \u00c4nderung 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\u00e4hnt, dass die \u00c4nderung zu Problemen beim Booten von ISO-Images \u00e4lterer Systeme f\u00fchren kann, die mit einer anf\u00e4lligen Version von GRUB ausgeliefert werden. Tats\u00e4chlich 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\u00e4lligkeit in GRUB bereits lange behoben ist. <\/p>\n
Das Problem \u00e4u\u00dfert 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 das System wieder zum Laufen zu bringen, wird empfohlen, die im UEFI gespeicherten SBAT-Daten zu l\u00f6schen. Dazu kann Secure Boot im BIOS deaktiviert werden, und ein aktuelles Linux-Distribution mit UEFI Secure Boot-Unterst\u00fctzung, wie Ubuntu, heruntergeladen werden. F\u00fchren Sie anschlie\u00dfend im Terminal den Befehl «mokutil —set-sbat-policy delete» aus und starten Sie die Linux-Distribution neu, um die korrekte SBAT-Politik zu installieren. Danach kann der Secure Boot-Modus im BIOS wieder aktiviert werden. <\/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 die digitale Signatur zur\u00fcckzuziehen. SBAT bedeutet, dass den ausf\u00fchrbaren Dateien von UEFI-Komponenten zus\u00e4tzliche Metadaten hinzugef\u00fcgt werden, die Informationen \u00fcber den Hersteller, das Produkt, die Komponente und die Version enthalten. Die angegebenen Metadaten werden durch eine digitale Signatur beglaubigt und k\u00f6nnen separat in die Listen der genehmigten oder gesperrten Komponenten f\u00fcr UEFI Secure Boot aufgenommen werden. SBAT erm\u00f6glicht das Blockieren der Verwendung digitaler Signaturen f\u00fcr bestimmte Versionsnummern von Komponenten, ohne dass Schl\u00fcssel f\u00fcr Secure Boot zur\u00fcckgezogen werden m\u00fcssen. <\/p>\n
Das Blockieren von Schwachstellen \u00fcber SBAT erfordert keinen Einsatz der UEFI-Zertifikat-Widerrufsliste (dbx), sondern erfolgt auf der Ebene des Austauschs des internen Schl\u00fcssels 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\u00fcr die vollst\u00e4ndige Blockierung einer Schwachstelle, da ein Angreifer, unabh\u00e4ngig vom verwendeten Betriebssystem, ein bootf\u00e4higes Medium mit einer alten anf\u00e4lligen Version von GRUB2, die durch eine digitale Signatur beglaubigt war, zur Kompromittierung von UEFI Secure Boot verwenden konnte. \n Quelle: opennet.ru<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"