[Uwe Farz]

Ich bin ja der Meinung von mir bezahlte teuere Hardware ist mein Eigentum und da hat niemand von aussen reinzumurksen.
In Redmond sieht man das mal wieder ganz anders:

Windows-Update legt erneut Linuxe lahm

Mit den Windows-Updates vom 13. August booten verschiedene Linux-Installationsmedien nicht mehr. Das liegt an veralteten Bootloadern, die nun gesperrt wurden.


Windows-Update sperrt wieder einmal einige Linux-Bootloader aus.

Und täglich grüßt das Windows-Update: Manche Windows-Rechner, auf denen das am 13. August veröffentlichte Update installiert wurde, starten die Installationsmedien und Live-Systeme mancher Linux-Distributionen nicht mehr. Betroffen ist nach unseren Recherchen auch das aktuelle Ubuntu 24.04 LTS sowie darauf aufsetzende Live-Systeme wie zum Beispiel Desinfec't.

Die Ursachen sind, wie auch bei vorherigen Windows-Updates, die Linuxe am Booten hinderten, veraltete Linux-Bootloader, die bereits seit einiger Zeit als unsicher bekannt sind. Während es bei früheren Updates Blacklist-Einträge in der DBX-Datenbank von Secure Boot waren, die die Linux-Bootloader ausbremsten, hat Microsoft mit dem Update (KB5041571) und KB5041580) für Windows 10 und 11 das von der Open-Source-Gemeinde entwickelte Secure Boot Advanced Targeting (SBAT) nachgerüstet. Damit soll das Speicherproblem im BIOS einiger Mainboards gelöst werden, die nur begrenzt Platz für die DBX-Datenbank mit Signaturen angreifbarer Bootloader bieten.

SBAT statt DBX-Datenbank

Während bei den DBX-Einträgen das UEFI-BIOS den Systemstart eines als unsicher erkannten Bootloaders verweigert, sind es bei SBAT die Linux-Bootloader Shim und Grub, die erkennen, dass Secure Boot nicht mehr gewährleistet ist und deshalb den Dienst versagen. Optimierungen sollen außerdem dafür sorgen, dass SBAT-Sperrlisten möglichst klein bleiben. Allerdings beseitigt das nicht die Abhängigkeit von Microsoft, den Linux-Bootloader Shim immer wieder für Secure Boot zertifizieren und signieren lassen zu müssen: Secure Boot starten auch weiterhin nur signierte Bootloader aus vertrauenswürdiger Quelle – und das ist bei so gut wie allen Hardware-Herstellern immer noch nur Microsoft. Indem diese Bootloader aber nun via SBAT außer Betrieb gesetzt werden können, wenn sie sich als fehlerhaft erweisen, muss kein neuer Eintrag zur DBX-Blacklist hinzugefügt werden.

Unklar ist aktuell noch, welche Systeme und Distributionen von den neuerlichen Bootproblemen betroffen sind. So gibt Microsoft in dem Knowledge-Base-Eintrag an, das Update gelte "nicht für Systeme, auf denen Windows und Linux dual gestartet werden." Es gibt aber bereits Berichte, wonach das Update auch auf Systemen mit Parallelinstallationen verhindern soll, dass Linux-Sticks starten. Auf anderen Systemen, so zeigen es unsere eigenen Tests, bootet Ubuntu 24.04 LTS auch weiterhin anstandslos. Bereits auf Festplatte oder SSD installierte Linux-Systeme, auf denen die aktuellen Updates eingespielt wurden, booten in jedem Fall auch weiterhin.

Warten auf neue Images

Um das Problem der veralteten Bootloader zu lösen, müssen die betroffenen Distributoren wieder einmal ihre Installationsmedien aktualisieren, was einige Tage in Anspruch nehmen dürfte. Alternativ können Sie Secure Boot auf Ihrem Rechner deaktivieren – allerdings nur, wenn Sie vorher den Bitlocker-Wiederherstellungsschlüssel notiert oder ausgedruckt haben. Denn mitunter reagieren verschlüsselte Windows-Installationen allergisch auf Änderungen bei Secure Boot und verlangen dann beim nächsten Start die Eingabe des Schlüssels.
Quelle:[ Link nur für registrierte Mitglieder sichtbar. Bitte einloggen oder neu registrieren ]

SecureBoot im Zusammenhang mit Windows klingt inzwischen ohnehin nur noch wie Realsatire, während die Liste der Übergriffe immer länger wird.
Meine Abneigung gegenüber Microsoft wird durch solche Dinge keineswegs weniger.

[Draalz]

Zitat von Uwe Farz

SecureBoot im Zusammenhang mit Windows klingt inzwischen ohnehin nur noch wie Realsatire

Selbst wenn ich mal ein Windows hochfahre, ist das eine Lachnummer.
Grub unter Debian ist derzeit nicht behindert und in dieser Community würde kein Mensch auf die Idee kommen Secure Boot ins Schiff zu stellen.

[Uwe Farz]

Hier zusätzlich noch ein Artikel von Günter Born:

Windows August 2024-Update legt Linux-Boot lahm

Publiziert am 19. August 2024 von Günter Born

Nutzer, die Windows und Linux über Secure Boot auf Rechnern verwenden, dürften seit dem 13. August 2024 ein Problem haben. Microsoft hat mit dem August 2024 Patchday etwas am Boot-Prozess geändert und Boot-Einträge von DBX auf Secure Boot Advanced Targeting (SBAT) umgestellt. Als Folge starten Linux-Installationen auf den betreffenden Systemen nicht mehr im Secure Boot-Modus. Die bedeutet imho, den Secure Boot-Modus abschalten und auf aktualisierte Linux-Distributionen warten.

SBAT durch August 2024-Updates

Ich habe es nur am Rande wahrgenommen, Microsoft hat bei den Updates für Windows im August 2024 Secure Boot Advanced Targeting (SBAT) für alle unterstützten Windows Versionen eingeführt. In den betreffenden Supportbeiträgen heißt es dazu:

[Secure Boot Advanced Targeting (SBAT) and Linux Extensible Firmware Interface (EFI)] This update applies SBAT to systems that run Windows. This stops vulnerable Linux EFI (Shim bootloaders) from running. This SBAT update will not apply to systems that dual-boot Windows and Linux. After the SBAT update is applied, older Linux ISO images might not boot. If this occurs, work with your Linux vendor to get an updated ISO image.

Diese Updates führen Secure Boot Advanced Targeting (SBAT) auf Windows-Systemen ein. Ziel ist es, zu verhindern, dass anfällige Linux EFI (Shim-Bootloader) ausgeführt werden. Microsoft schreibt dabei: "Dieses SBAT-Update gilt nicht für Systeme, die Windows und Linux im Dual-Boot-Modus ausführen" und warnt gleichzeitig: "Nach der Anwendung des SBAT-Updates lassen sich ältere Linux-ISO-Images möglicherweise nicht mehr booten. Wenden Sie sich in diesem Fall an Ihren Linux-Anbieter, um ein aktualisiertes ISO-Image zu erhalten."

Lesermeldungen über Boot-Probleme

In diesem Kommentar fragte FFred nach Informationen nach den Folgen der Einführung von Secure Boot Advanced Targeting (SBAT), und Bolko verwies auf einen Beitrag bei heise, wo Probleme mit dem Booten von Linux-Systemen thematisiert wurden. Leser Paul meldete sich in diesem Kommentar und berichtete von Boot-Problemen.

Sowas habe ich heute NACH dem Augustupdate KB5041580 (W10) mit meinem Ventoy USB-Stick (UEFI, Version 1.0.9 festgestellt, der VOR diesem Update n0ch bei eingeschaltetem Secure-Boot funktionierte.
Beim Bootversuch vom USB-Stick kam eine Fehlermeldung, die ich so zum ersten mal sah:
———————–
Verifying shim SBAT data failed: Security Policy Violation
Something has gone seriously wrong: SBAT self-check failed: Security Policy Violation
———————–
Die Meldung erschien für gut 5 Sekunden auf schwarzem Hintergrund und dann schaltete sich der Rechner aus.
Nach dem Ausschalten von Secure-Boot ging es dann.

Da hat ihm das Windowsupdate wohl seinen Sicherheitsschlüssel aus dem BIOS weggeputzt, vermute ich.

Blog-Leser Peter hat sich zum 18. August 2024 mit diesem Kommentar gemeldet und schreibt, dass SBAT nach dem August 2024-Update – im Gegensatz zu obiger Microsoft-Aussage – auch im Dual Boot-Betrieb ausgeführt werde. Auch er erhielt die Meldung "Verifying shim SBAT data failed: Security Policy Violation" und der Rechner schaltet sich aus. Einzige Lösung ist, Secure Boot für die Maschine abzuschalten.

Noch eine Meldung mit Workaround

Ich hatte bereits einen Blog-Beitrag zum Thema auf dem Schirm, als noch die Mail von Blog-Leser Tibor eintraf, der nach Installation des Windows 11-Updates beim Start des Systems mit der Fehlermeldung:

Verifying shim SBAT data failed: Security Policy Validation

beglückt wurde. Der betreffende Rechner hat sich nach Sekunden abgeschaltet. Er betreibt auf seinem Rechner Linux Mint 20.3 und Windows 11 im Dual Boot. Als er dann zum Thema recherchierte, kam er dem oben skizzierten Grund auf die Spur und schrieb:

Recherchen zu diesem Begriff machten mich völlig fassungslos: Microsoft hat in meinem UEFI BIOS mit aktiviertem Secure Boot
und TPM herumgepfuscht, sodass ich nun nur noch Windows 11 mit aktiviertem Secure Boot starten konnte.
Ohne Secure Boot ging beides!

Nach langem Suchen hat er zwei Lösungen in Foren gefunden und diese dann für sich kombiniert. Das hat ihm letztendlich (in seinem Fall) geholfen:

1. Disable Secure Boot
2. Boot linux mint 22 from Boot stick
3. open a terminal
4. Delete the SBAT policy with:
sudo mokutil –set-sbat-policy delete
sudo mokutil –list-sbat-revocations (sollte nur 1 eintrag sein)
5. Reboot and re-enable secure boot in your BIOS.
6. Reboot your PC and log back into Ubuntu to update the SBAT policy with
sudo mokutil –set-sbat-policy latest

Der Leser schrieb dazu noch, dass es Ankündigungen von Microsoft dazu bereits gab. Aber niemand hatte wohl auf dem Radar, dass sich das so heftig auswirkt. Der Leser merkte noch an, dass bei einigen älteren PC´s mit 3. Generation Intel-CPU noch nicht mal die obige Fehlermeldung angezeigt wird. Stattdessen verabschiedet sich das Gerät in eine Bootschleife. Er sieht die Linux Community teilweise in der Schuld, da dort immer wieder zum Abschalten von Secure Boot geraten werde.

Alpträume wahr geworden

Wenn ich es richtig in Erinnerung habe, warnten Entwickler aus der Linux-Community bereits vor mehr als 14 Jahren, dass Microsofts Secure Boot der Kill-Switch sei, um Linux auf Windows-Rechnern still zu legen. Aus der Windows-Ecke hieß es immer, dass die Linux-Entwickler ja nur einen gültigen Secure Boot-Lader bereitstellen müssten. In Folge wurden solche Lader für Linux entwickelt, so dass Systeme mit Secure Boot sowohl Windows als auch Linux booten konnten.

Nun ist also ein solches Szenario wahr geworden – heise hat es hier beschrieben. Bisher wurden die benötigten Signaturen zum Booten in der DBX-Datenbank des BIOS/UEFI abgelegt. Heise schreibt, dass diese Datenbank bei einigen BIOS-Systemen zu klein für viele Signatur-Einträge sei. Mit den August 2024-Updates wurde nun von Microsoft das von der Open-Source-Community entwickelte Secure Boot Advanced Targeting (SBAT) nachgerüstet – eine Erklärung zum UEFI shim-Boot-Loader findet sich hier.

Mit den August 2024-Updates hat Microsoft begonnen, die in der UEFI DBX-Datenbank hinterlegten Keys für die Boot-Lader zu sperren. Nun seien es die Linux-Boot-Loader Shim und Grub, die einen Systemstart verweigern, weil die Integrität des Secure Boot nicht mehr gewährleistet ist, erklärt heise. Auf Hacker News gibt es hier noch einen Erklärungsversuch. Momentan ist unklar, welche Linux-Distributionen betroffen sind. Aktuell heißt es zur Lösung aber wohl "Secure Boot abschalten und auf eine aktualisierte Linux-Distribution warten", um das Problem zu lösen.

Alles Probleme, die der Nutzer nicht braucht. Und ob die Systeme durch Secure Boot und obige Schlenker wirklich sicherer werden, darf bezweifelt werden.

Weitere Links in der Quelle:[ Link nur für registrierte Mitglieder sichtbar. Bitte einloggen oder neu registrieren ]

Das ist schon mehr als übergriffig.

[Draalz]

Microsoft reagiert auf lahmgelegte Linux-Bootloader durch Windows Update

Die Windows-Updates aus dem August haben Linuxe lahmgelegt und diese am Booten gehindert. Microsoft benennt nun die Ursache.


(Bild: Bild erstellt mit KI in Bing Designer durch heise online / dmk)

09:17 Uhr Lesezeit: 3 Min. Security

Von [ Link nur für registrierte Mitglieder sichtbar. Bitte einloggen oder neu registrieren ]

Am Wochenende kristallisierte sich heraus, dass die Windows Updates im August dafür sorgten, dass zahlreiche Linux-Distributionen nicht mehr starteten. Ursache sind durch die Windows Updates gesperrte Bootloader – Microsoft erklärt nun, dass zu viele gesperrt wurden.

In einem Eintrag im [ Link nur für registrierte Mitglieder sichtbar. Bitte einloggen oder neu registrieren ], dass es nach der Installation der Windows-Updates aus dem August zu Startproblemen mit Linux kommen könne, sofern der Dual-Boot-Betrieb mit Windows und Linux eingerichtet wurde. Im Ergebnis könne das Gerät Linux nicht starten und die Fehlermeldung "Verifying shim SBAT data failed: Security Policy Violation. Something has gone seriously wrong: SBAT self-check failed: Security Policy Violation" anzeigen.

Einstellungsänderung in SBAT

Das August-Update füge eine Einstellung zum Secure Boot Advanced Targeting (SBAT) auf Geräten hinzu, auf denen Windows läuft, um alte, verwundbare Bootmanager zu blockieren. Dieses SBAT-Update wird nicht auf Geräten installiert, auf denen eine Dual-Boot-Konfiguration zum Einsatz kommt. Auf einigen Geräten sei diese Erkennung fehlgeschlagen, da dort etwa angepasste Dual-Boot-Optionen genutzt werden, wodurch die SBAT-Änderungen ergänzt wurden, obwohl das nicht geschehen sollte, erörtert Microsoft.

Die Autoren schlagen einen etwas halbherzigen Workaround vor: Sofern die Installation des August-Updates noch nicht mit einem Reboot abgeschlossen wurde, können potenziell Betroffene einen Registry-Schlüssel zum Opt-out nutzen, sodass das SBAT-Update nicht installiert wird. Der Schlüssel lasse sich später auch wieder löschen, wenn doch SBAT-Updates installiert werden sollen. Der Befehl zum Ergänzen des Schlüssels lautet laut Microsoft:

reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot\SBAT /v OptOut /d 1 /t REG_DWORD

Microsoft ist den eigenen Angaben nach weiter dabei, das Problem zusammen mit den Linux-Partnern des Unternehmens zu untersuchen. Sofern dabei weitere Informationen herauskommen, will Microsoft diese herausgeben. Als betroffene Windows-Versionen listet Microsoft Windows 11 23H2, 22H2, 21H2, Windows 10 22H2, 21H2 und Windows 10 Enterprise 2015 LTSB sowie die Windows Server 2022, 2019, 2016, 2012 R2 und 2012.

Betroffenen bleibt im Regelfall also weiterhin nur, auf aktualisierte Images der Linux-Distributionen zu warten, die sich aufgrund aktualisierter Bootloader starten lassen. Als weitere Umgehungsmaßnahme können Betroffene Secure Boot deaktivieren – sie sollten jedoch sicherstellen, dann Sicherheitskopien der Bitlocker-Wiederherstellungsschlüssel im Zugriff zu haben, da Windows mitunter beim Start mit der Abfrage dieser Schlüssel auf Änderungen bei Secure Boot reagiert.

Am vergangenen Samstag wurde deutlich, dass die Windows Updates aus der Nacht zum vergangenen Mittwoch dafür sorgten, dass einige Installationsmedien und Live-Systeme von Linux-Distributionen nicht mehr starteten. Das betrifft auch populäre Distributionen wie Ubuntu 24.04 LTS oder darauf basierende Live-Systeme wie Desinfec't. Diese nutzen offenbar veraltete Bootloader, die durch [ Link nur für registrierte Mitglieder sichtbar. Bitte einloggen oder neu registrieren ] als unsicher markiert werden.

[ Link nur für registrierte Mitglieder sichtbar. Bitte einloggen oder neu registrieren ]
Sicherlich habe ich meine Rechner nicht in einem Tresor stehen, aber relevante Daten werden auf einem ohne Secure Boot startendem NAS gespeichert, dessen Festplatten verschlüsselt sind. Den kannste ja mal hochfahren und versuchen Daten auszulesen.

[Uwe Farz]

Am Wochenende kristallisierte sich heraus, dass die Windows Updates im August dafür sorgten, dass zahlreiche Linux-Distributionen nicht mehr starteten. Ursache sind durch die Windows Updates gesperrte Bootloader – Microsoft erklärt nun, dass zu viele gesperrt wurden.

Scheinheilige Pharisäer. Der Shitstorm ist wohl zu groß geworden.
Die Folterwerkzeuge zum Ausbau des Quasimonopols sind vielfältig.
Microsoft sagt mir im Updatebereich meines Windows 10 Enterprise "Dieser PC erfüllt derzeit nicht die Mindestsystemanforderungen, um Windows 11 auszuführen".
An der Hardware liegt es nicht, aber "Secure Boot" ist deaktiviert und das bleibt auch so, weil die in meinem BIOS nichts verloren haben.

[Draalz]

Zitat von Uwe Farz

Microsoft sagt mir im Updatebereich meines Windows 10 Enterprise "Dieser PC erfüllt derzeit nicht die Mindestsystemanforderungen, um Windows 11 auszuführen".
An der Hardware liegt es nicht, aber "Secure Boot" ist deaktiviert und das bleibt auch so, weil die in meinem BIOS nichts verloren haben.

Wenn auch OT, schau Dir das mal an:

[ Link nur für registrierte Mitglieder sichtbar. Bitte einloggen oder neu registrieren ]

[rexgullx]

Noch funktioniert diese Methode. Sie wird aber zukünftig geblockt:

Microsoft schließt im Windows 11 Canary Build 27686 [ Link nur für registrierte Mitglieder sichtbar. Bitte einloggen oder neu registrieren ] für Windows 11 Systemanforderungen.

Es bleibt bei Microsofts Salamitaktik die Daumenschrauben stetig weiter anzuziehen.

[Uwe Farz]

Zitat von rexgullx

Es bleibt bei Microsofts Salamitaktik die Daumenschrauben stetig weiter anzuziehen.

So siehts aus. Windows 11 User werden sich noch wundern.

[Draalz]

Danke nochmals für diesen Hinweis.
Ich denke, jetzt droht dieses Thema weit OffTopic zu geraten, aber es wirft halt Fragen auf.
Also bitte Avantasia, wenn das hier nicht mehr hineinpasst, könntest Du verschieben?

Zitat von rexgullx

Es bleibt bei Microsofts Salamitaktik die Daumenschrauben stetig weiter anzuziehen.

Die Frage, die ich mir bei sowas stelle ist: Was haben die davon? Orientieren sie sich jetzt an MacIntosh, die ja auch schon jahrelang die Systemanforderungen ihrer Betriebssysteme hochgefahren haben?
Seit 20 Jahren ist fast jedes Linux Betriebssystem einfacher zu installieren als Windows. Setzen sie jetzt auf den Klüngel der Benutzer, nach dem Motto: Du brauchst einen moderneren Rechner?
Naja, dieses ganze Vorgehen ist wohl, denke ich, auf Firmen ausgelegt, die Microsoft Produkte verwenden und nun evtl. ihre Hardware neu kaufen müssen. Das bringt halt viel Umsatz.