[English]Kurze Rundfrage unter der Leserschaft des Blogs, die Windows 11-Maschinen im Einsatz haben. Hat es bei eurem Bestand Rückmeldungen über TPM-Fehler gegeben, nachdem die Sicherheitsupdates für Windows 11 im April 2024 auf Geräten installiert wurden? Ein Leser hat mich per Mail kontaktiert, weil in seinem Umfeld Enterprise-Systeme mit Secure Boot-Fehler mucken. Hier ein kurzer Überblick, was mir durch den Fall bekannt ist.
Sicherheitsupdates April 2024
Für Windows 11 23H2-22H2 gab es zum 9. April 2024 ja das kumulative Sicherheitsupdate KB5036893, welches auch die neuen Funktionen des Element 5-Updates einführte. Ich hatte Hinweise zum Update im Blog-Beitrag Patchday: Windows 11/Server 2022-Updates (9. April 2024) veröffentlicht. Details zu den Korrekturen des Updates finden sich im Support-Beitrag.
Problem mit TPM
Blog-Leser Alex T. hat sich bei mir per Mail mit einer (Einzel-)Beobachtung gemeldet, von der ich wissen möchte, ob es ggf. noch mehr Betroffene gibt. Zum Hintergrund: Der Leser arbeitet in einem Kleinunternehmen, welches der Softwareentwicklung betreibt, schreibt aber, dass IT-Kenntnisse nur begrenzt vorhanden seien.
In der Firma ist unter anderem ein PC mit Windows 11 Enterprise vorhanden. Laut Alex wurde dieser Rechner mal mit Windows 10 Enterprise betrieben, dann aber – ohne weitere Tricks – auf Windows 11 Enterprise aktualisiert. Das System lief bisher unauffällig mit Windows 11 Enterprise, so dass dort am 10. April 2024 das monatliche Sicherheitsupdate für Windows 11 durchgeführte wurde.
Das System wurde erst am 13. April 2024 erneut hochgefahren. Bei diesem Hochfahren und seitdem bei jedem Systemstart zeigt die Ereignisanzeige von Windows einen Secure Boot-Fehler an.
Windows 11 beschwert sich, dass das Secure Boot-Update dabei gescheitert sei, die Secure Boot-Variable zu aktualisieren. Grund seit, dass Secure Boot auf der Maschine nicht aktiviert sei. Laut Leser gibt es bis jetzt keine weiteren Beschwerden, und alle anderen PCs (alles Windows 10) sind unauffällig. Der Leser schreibt noch, dass Secure Boot laut Windows Systeminfo in der Tat ausgeschaltet sei. Ob Secure Boot vorher aktiviert war, kann der Leser nicht beantworten.
Das System läuft mit einem Intel i7-8700-Prozessor und ist Windows 11-fähig. Es seit bereits 2203 ohne Frickelei und Tricks, durch einfache Bestätigung im Windows Update, auf Windows 11 migriert. Seit diesem Upgrade lief die Maschine mit Windows 11 Enterprise ohne Murren durch alle Updates. Und im BIOS herumgepfuscht hat seitdem – gemäß aktuellem Wissenstand – niemand.
Der Leser meint dazu: „Kann man natürlich auch ignorieren, oder man kann Secure Boot im BIOS (wieder?) einschalten oder daran herumwackeln. Allerdings haben Windows 11 und Secure Boot ja eine „besondere Beziehung“, weswegen ich doch lieber erst einmal abwarte und herumfrage, ob sowas schon anderswo gesehen wurde, und ob man jetzt am Secure Boot Schalter im BIOS noch ungestraft drehen darf.„
Ähnliche Artikel:
Office Updates vom 2. April 2024
Microsoft Security Update Summary (9. April 2024)
Patchday: Windows 10-Updates (9. April 2024)
Patchday: Windows 11/Server 2022-Updates (9. April 2024)
Windows Server 2012 / R2 und Windows 7 (9. April 2024)
Microsoft Office Updates (9. April 2024)
Ja, gibt es! Folgende Fehlermeldung tritt bei jedem Systemneustart einmalig in der Ereignisanzeige auf (Windows 11 Pro 23/H2 – Privatanwender – kein Netzwerk – kein Windows 10 zuvor, sondern Neuinstallation mit Windows 11 im März 2023):
„Beim Update für den sicheren Start konnte eine Variable für den sicheren Start nicht aktualisiert werden. Fehler: Sicheres Starten ist auf diesem Computer nicht aktiviert. Weitere Informationen finden Sie unter https[:]//go.microsoft.com/fwlink/?linkid=2169931“
Sicherer Start, der zuvor aktiv war, lt. Systeminfo seither auch hier ausgeschaltet! Werde das auch zunächst mal so lassen, da das System soweit einwandfrei funktioniert und ich inzwischen echt keinen Bock mehr habe, mich ständig um Microsofts Befindlichkeiten zu kümmern (und damit oft noch Schlimmeres zu bewirken).
Weiterhin lässt sich das Profilbild seit diesem Update nicht mehr abändern und ist nur noch beim Anmeldedialog zu sehen, nicht aber in den „Einstellungen“ „links oben am Bildschirmrand“. Dort ist nur noch das graue Standard-Bild mit „Strichmännchen“ zu sehen …
Der LSA-Fehler im Defender hatte auch inzwischen einjährigen Geburtstag – erste Meldung im März 2023 … (https[:]//www.borncity.com/blog/2023/07/06/microsoft-fixt-windows-defender-lsa-problem-in-windows-11-mit-update-kb5007651-version-1-0-2306-10002/)
Und auch die – angeblich schon vor zwei, oder sogar drei Monaten behobenen – „Metadaten-Staging/DeviceSetupManager-Fehler“ (https[:]//www.borncity.com/blog/2023/12/11/windows-meldet-metadata-staging-error-0x80070490-dez-2023/#comment-180517) sind nach diesem Update noch immer vorhanden …
Aber die Hauptsache wir haben neue „Snap-Layouts“ bekommen (die kein Mensch braucht …) Die Prioritätensetzung bei MS lässt einem immer wieder schier den Atem stocken.
GB: *** Ich habe den Kommentarthread komplett gelöscht, da er außer persönlichen Beschimpfungen nichts beigetragen hat – ist für das Artikelthema nicht gegenständlich und gehört nicht in die Kommentare. Danke für euer Verständnis – bei weiteren persönlichen Beharkungen behalte ich mir vor, einzelne Teilnehmer auch für Kommentare zu sperren. ***
Ist dir schonmal in den Sinn gekommen, dass es auch bei privaten PCs gewünschte/erforderliche Software gibt, die unter Linux/MacOS ums Verrecken nicht läuft?
> Der Leser schreibt noch, dass Secure Boot laut Windows Systeminfo in der Tat ausgeschaltet sei. Ob Secure Boot vorher aktiviert war, kann der Leser nicht beantworten. <
Einschlägig ist wohl Artikel (1) welcher gem. auzuklappendem Abschnitt "Change log" am 09.04.2024 aktualisiert wurde.
Der Artikel geht implizit davon aus, dass sich heutzutage niemand mehr die Fahrlässigkeit leistet, ohne aktiviertes Secure Boot unterwegs zu sein, Zitat: "Secure Boot helps prevent bootkit malware in the boot sequence. Disabling Secure Boot puts a device at risk of being infected by bootkit malware."
Allerdings schützte Secure Boot bis anhin nicht vor dem BlackLotus UEFI bootkit, weshalb es des "Windows security update released on or after April 9, 2024" bedarf und zusätzlich (!) zwei weiterer im Abschnitt "Take Action" aufgeführten Schritte.
Man beachte auch, dass u. a. im auszuklappenden Abschnitt „May 9, 2023 – Initial Deployment Phase“ vermerkt ist: „This phase has been superseded by the Windows security updates release on or after April 9, 2024.“ Es scheint sich hier eine ziemlich verwirrende Dynamik entfesselt zu haben.
(1)
support.microsoft.com/en-us/topic/kb5025885-how-to-manage-the-windows-boot-manager-revocations-for-secure-boot-changes-associated-with-cve-2023-24932-41a975df-beb2-40c1-99a3-b3ff139f832d
Ich habe diesen Artikel vorhin mal „durchgeackert“ und folgender Sachverhalt trifft auf mich – zumindest indirekt – zu, da ich natürlich nicht Windows Server habe, aber auch TPM 2.0! Also würde dies hier auch wieder mal heißen „abwarten und Tee/Kaffee trinken“!?:
„TPM 2.0-basierte Systeme: Diese Systeme, in denen Windows Server 2012 und Windows Server 2012 R2 ausgeführt werden, können die im Sicherheitsupdate vom 9. April 2024 veröffentlichten Mechanismen zur Risikominderung aufgrund bekannter Kompatibilitätsprobleme mit TPM-Messungen nicht bereitstellen. Die Sicherheitsupdates vom 9. April 2024 blockieren die Risikominderungsmechanismen Nr. 2 (Start-Manager) und Nr. 3 (DBX-Update) auf betroffenen Systemen.
Microsoft ist das Problem bekannt, und ein Update wird in Zukunft veröffentlicht, um die Blockierung von TPM 2.0-basierten Systemen aufzuheben.“
Sollte sich eher nur auf Windows Server 2012 und 2012 R2 beziehen, da sonst eigentlich ein grosser Anteil/fast alle in den letzten Jahren vertriebenen PCs und vermutlich alle Server ausgeschlossen wären. Das würde ein so gross angelegtes Update sinnfrei machen.
Die in dem verlinkten Artikel beschriebenen Schritte liessen sich auch auf 2 Rechnern mit TPM 2.0 und Bitlocker durchführen (W10Pro, BitlockerKey Protectors: TPM And PIN, Numerical Password)
Ist auch unter Windows 10 so.
„Das Secure Boot-Update konnte eine Secure Boot-Variable mit dem Fehler Sicheres Starten ist auf diesem Computer nicht aktiviert. nicht aktualisieren. Weitere Informationen finden Sie unter https://go.microsoft.com/fwlink/?linkid=2169931„
Der Fehler mit der ID 1796 wird in [1] beschrieben als:
„Wenn die aktualisierte DBX-Sperrliste auf ein Gerät angewendet wird und ein Fehler auftritt, der nicht durch die oben genannten Ereignisse abgedeckt ist, wird ein Ereignis protokolliert, und Windows versucht, die DBX-Liste beim nächsten Systemneustart auf die Firmware anzuwenden.
Informationen zum Ereignisprotokoll
Ereignis-ID 1796 tritt auf, wenn ein unerwarteter Fehler auftritt. Der Eintrag im Ereignisprotokoll enthält den Fehlercode für den unerwarteten Fehler.“
Hilft nicht wirklich weiter…
Ein Einstieg in die Thematik kann auch der am 24.04.2024 aktualisierte Artikel [2] von Microsoft sein. Aber ganz ehrlich, ich habe die Thematik trotz c’t Artikelreihe in Heft 7/2024 und Ergänzung zu Secure Boot unter Linux in Heft 9/2024 nicht gänzlich durchdrungen. Mir tun diejenigen leid, die es mit einem Zoo an unterschiedlicher Hardware zur „Enforcement Phase“ genannt in [1] zu tun haben werden. Diese Phase war mal zum Oktober 2024 geplant aber offenbar bekommt auch Microsoft kalte Füße mit dem Thema.
[1] https://support.microsoft.com/en-us/topic/kb5025885-how-to-manage-the-windows-boot-manager-revocations-for-secure-boot-changes-associated-with-cve-2023-24932-41a975df-beb2-40c1-99a3-b3ff139f832d?preview=true
[2] https://techcommunity.microsoft.com/t5/windows-it-pro-blog/revoking-vulnerable-windows-boot-managers/ba-p/4121735
Die c’t Artikelreihe spricht vom Bootloader (\efi\boot\bootx64.efi), der verlinkte MS Artikel spricht vom Bootmanager (\efi\microsoft\boot\bootmgfw.efi). Anscheinend sind beide Dateien aber (seit längerem?) identisch.
Für den Austausch des Bootloaders wurde der Hash des unsicheren Bootloaders in die in der Firmware (NVRAM „im bios“) sitzende Datenbank verbotener Hashes geschrieben. Da aber bei älteren Rechnern der Platz im NVRAM begrenzt ist, hat sich MS die CodeIntegrityPolicy ausgedacht, die unsichere Hashes in EFI\Microsoft\Boot\SkuSiPolicy.p7b speichert.
Die Firmware prüft die Signatur des Bootloaders gegen das in der Firmware hinterlegte Zertifikat und prüft danach, ob dessen Hash in der (zu kleinen / ggf. unvollständigen) dbx mit ungültigen Hashes hinterlegt ist.
Danach geht die Kontrolle an den Bootloader, der Windows startet und via SkuSiPolicy.p7b prüft, ob der Bootloader überhaupt hätte gestartet werden dürfen. Soweit entsprechend Heise.
Die neue Runde bezieht sich wieder auf den Bootmanager (und Bootloader) und ein zusätzliches, grundsätzliches Problem: Das auslaufende UEFI Zertifikat von 2011. Diese wird jetzt ersetzt, Bootmanager und Bootloader mit einer mit dem UEFI Zerifikat von 2023 signierten Version ersetzt und das UEFI Zertifikat von 2011 wird dann in der (immer noch zu kleinen) dbx (und vermutlich in SkuSiPolicy.p7b) für ungültig erklärt.
Interessanterweise wurde bei ersten Aktion Bootloader (und Bootmanager?) durch einen neueren, erstmal immer noch mit dem Microsoft Windows Production PCA 2011 Zertifikat signierten ersetzt und (wohl) nur eine ganze Menge Einzel- Hashes für alte Bootloader/ Bootmanager in der dbx/SkuSiPolicy.p7b gespeichert. (Das war die Runde mit 0x30 in der registry zum Aktivieren und ID 276 „Windows boot manager revocation policy version 0x2000000000002 is applied.“ als Erfolgsmeldung- siehe ältere Versionen des Artikels bis einschl. 04.04.24)
Für ältere Versionen des MS- Artikels:
http://web.archive.org/web/20230801000000*/https://support.microsoft.com/en-us/topic/kb5025885-how-to-manage-the-windows-boot-manager-revocations-for-secure-boot-changes-associated-with-cve-2023-24932-41a975df-beb2-40c1-99a3-b3ff139f832d
KB5016061: Secure Boot DB and DBX variable update events
https://support.microsoft.com/en-us/topic/kb5016061-secure-boot-db-and-dbx-variable-update-events-37e47cf8-608b-4a87-8175-bdead630eb69
Immerhin nett zu lesen, dass das Update (anscheinend) prüft, ob das 2023 Zertifikat installiert ist und ob alle Teile des Bootprozesses korrekt zertifiziert sind- zumindest gibt’s Fehlermeldungen dafür.
ID 1796 würde m.E. Fehler beim Aktualisierien der Datenbank mit den verbotenen Hashes schliessen. Anscheinend enthält das April update ein dbx update für das UEFI Zertifikat 2023, das manuell angestossen werden muss, und ein ‚allgemeines‘ Update, das in jedem Fall durchgeführt wird. Kann dieses Update nicht installiert werden (NVRAM voll/dbx zu gross), wird Secure Boot deaktiviert, da unsichere Bootloader nicht mehr ausgeschlossen werden können?
Ich bin mir jetzt nicht sicher, ob mein Kommentar jetzt hier passt. Mein Problem war, dass ich seit drei oder vier Wochen nur einen WLAN Download von 400 MB bei einem 1 GB Vertrag habe. Da ich keinen Fehler finden konnte, wollte ich (OS ist WIN 11 23H2) schlicht und einfach ein Reparaturupdate machen. Dies wurde aber abgebrochen, weil ich kein TPM 2.0 hätte. Jetzt fing nun die Sucherei nach dem Problem TPM 2.0 an. Laut UEFI habe ich aber dort TPM installiert und enabled. tmp.msc sagt, ich habe kein tmp. Gerätesicherheit sagt noch „die Standarthardwaresicherheit wir nicht unterstützt“. Wie ich das in Ordnung bringen soll ohne meinen PC komplett neu aufzusetzten, ist mir schleierhaft. Lösung im WEB habe ich keine gefunden. Ein Mitarbeiter von Outbyte PC Repair wollte mir helfen, ist aber gescheitert. Ansonsten läuft meine PC ohne mucken.