FAQ: Das Secure-Boot-Desaster

c’t berichtete mehrfach über die aktuellen Sicherheitsprobleme rund um UEFI Secure Boot. Microsofts mehrfache Planänderungen zogen viele Fragen nach sich. Hier beantworten wir besonders oft gestellte – beschränken uns aber auf jene, bei denen wir davon ausgehen, dass die Antworten auch dann noch korrekt sind, falls Microsoft seine Pläne ein weiteres Mal umwirft.

Worum es geht

Secure Boot? UEFI? Zertifikate? Sicherheitsprobleme? Hä?

Es geht um das Abwehren von Schadsoftware, genauer von "Bootkits", die eine besonders fiese Malware-Variante darstellen. Denn sie nisten sich in den Bootloader ein und starten so noch vor dem eigentlichen Betriebssystem. Dadurch schützen sie sich besonders effektiv vor Entdeckung. "UEFI Secure Boot" dient als Gegenmaßnahme. Voraussetzung ist, dass der PC per UEFI bootet. Verwendet er stattdessen die Bootmechanismen eines klassischen Legacy BIOS, gibt es kein Secure Boot. Das gilt auch dann, wenn der PC zwar ein UEFI-BIOS besitzt, das Booten per Legacy BIOS aber per "Compatibility Support Module" (CSM) emuliert.

Wenn Secure Boot aktiv ist, übergibt das BIOS nach dem Einschalten des PCs die Kontrolle nur noch an Bootloader, die mit einem im Flashspeicher des BIOS hinterlegten Zertifikat signiert sind. Das Zertifikat stammt in den meisten Fällen von Microsoft. Das gilt auch für Linux (Microsoft signiert auch Linux-Loader).

Das Problem: Es gibt Sicherheitslücken in den Bootloadern, die das Einnisten von Schadsoftware wie "BlackLotus" erlauben. Damit ist Secure Boot aktuell ausgehebelt: Selbst wenn ein Bootloader mit einem gültigen Zertifikat signiert ist, bedeutet das nun trotzdem nicht mehr, dass er auch vertrauenswürdig ist. Also musste Microsoft Gegenmaßnahmen ergreifen, und um die geht es hier.

Der aktuelle Plan

Ich steige nicht durch, was Microsoft so alles an Gegenmaßnahmen zu den Secure-Boot-Lücken verkündet. Können Sie das kurz zusammenfassen?

An sich gern, aber nur mit einer Warnung vorab: Das ist der derzeit aktuelle Plan Microsofts, aber nicht der erste. So ganz verlässlich sind die Aussagen des Konzerns also nicht. Derzeit plant Microsoft, jenes Zertifikat zu widerrufen, mit dem bislang alle Secure-Boot-tauglichen Windows-Bootloader signiert wurden. Als Folge vertraut ein UEFI-BIOS bei aktivem Secure Boot keinem einzigen Windows-Bootloader mehr. Sie brauchen also erstens neue Bootloader. Die müssen zweitens mit einem neuen Zertifikat signiert sein, und das muss drittens im Flash-Speicher des BIOS hinterlegt werden.

Noch mal deutlich: Betroffen von diesem Plan sind nur die von Microsoft selbst veröffentlichten Windows-Bootloader. Was mit allen anderen ist, hat Microsoft bislang nicht gesagt.

Probleme vorprogrammiert

Was Sie schreiben, klingt so, als könnten Microsofts Pläne durchaus Grund zur Panik geben. Verstehe ich das so richtig?

Mal abgesehen davon, dass Panik grundsätzlich keine IT-Probleme löst: Microsoft will sowohl die neuen Bootloader als auch das neue Zertifikat automatisch per Windows-Update ausliefern. Schon jetzt räumt Microsoft in seinem Knowledge-Base-Artikel KB5025885 ein, dass es dabei Probleme geben wird (siehe ct.de/ys9k). Zudem erwies sich die Windows-eigene Update-Funktion in den letzten Jahren immer wieder als Quelle von Problemen statt Lösungen. Erst im Januar ging ein Update auf dermaßen vielen Rechnern schief, dass sich Microsoft die Frage gefallen lassen musste, ob Updates in Redmond überhaupt noch getestet werden.

Ich habe kein Secure Boot

Auf meinem PC ist Secure Boot nicht aktiv, also brauche ich weder neue Bootloader noch neue Zertifikate, oder?

An sich schon. Trotzdem wird Microsoft die Neuerungen per Update einspielen. Hintergrund: Microsofts für Secure Boot genutzte Zertifikate haben ein Zusatzproblem, sie laufen 2026 ab. Microsoft kann sie danach nicht mehr zum Signieren neuer Bootloader nutzen. Also spielt der Konzern kurzerhand überall neue Zertifikate ins BIOS und installiert neue Bootloader. Im Idealfall merken Sie auf Ihrem PC davon aber nichts.

Zertifikate im BIOS prüfen

Wie kann ich unter Windows herausfinden, welche Zertifikate im BIOS meines Rechners hinterlegt sind?

Es gibt kein Bordmittel, mit dem das einfach so geht, es existieren aber PowerShell-cmdlets zum Nachinstallieren. Die heißen "UEFIv2" und stammen vom (mittlerweile Ex-)Microsoft-Mitarbeiter Michael Niehaus. Veröffentlicht hat er sie online in der PowerShell-Gallery. Zum Nachinstallieren öffnen Sie eine mit Administratorrechten laufende PowerShell und tippen folgende drei Befehle ein:

Install-Module -Name UEFIv2
Set-ExecutionPolicy -ExecutionPolicy RemoteSigned
Import-Module UEFIv2

Der zweite Befehl löst einen Warnhinweis aus, den Sie bestätigen müssen. Der Befehl ist in der Standard-Konfiguration erforderlich (er erlaubt das Ausführen des cmdlets), doch wenn Sie ihn schon mal früher eingegeben haben, können Sie sich das Wiederholen sparen.

Ein weiterer Befehl namens Get-UEFISecureBootCerts liest anschließend die Zertifikate aus dem BIOS aus. Welche genau, hängt von der Abkürzung ab, die Sie an den Befehl anhängen. Von Interesse sind hier: DB, DBX und KEK. Die in der DB hinterlegten Zertifikate sind jene, die als Nachweis der Vertrauenswürdigkeit eines damit signierten Bootloaders dienen. Im Prinzip können hier auch Prüfsummen enthalten sein, das ist aber eher unüblich. Die DBX ist die dazu gehörende Sperrliste: Was hier drinsteht, verdient kein Vertrauen. Auch in der DBX können sowohl die Prüfsummen einzelner Loader als auch Zertifikate stecken. Der KEK (Key Exchange Key) berechtigt zu Änderungen an DB und DBX (genauer: damit signierte Software darf ändern).

Wir empfehlen, ein | fl an jeden Befehl anzuhängen, um die Ausgabe übersichtlicher als Liste zu gestalten (fl steht für format-list). Da vor allem die Ausgabe des Inhalts der DBX unübersichtlich sein kann (hier sind viele Prüfsummen schon ab Werk hinterlegt), sollten Sie zumindest diese Ausgabe in eine Textdatei umleiten. Ein kompletter Befehl zum Auslesen sieht wie folgt aus:

Get-UEFISecureBootCerts DB | fl >D:\Downloads\BIOS-Certs-DB.txt

Ersetzen Sie auf Wunsch DB durch DBX oder KEK. Pfad und Namen der Textdatei können Sie beliebig anpassen.

Bootloader prüfen

Wie finde ich heraus, mit welchem Zertifikat der Bootloader meiner Windows-Installation signiert wurde?

Das ist überraschend kompliziert. Es geht damit los, dass der Loader auf einer separaten Bootpartition (EFI System Partition, ESP) liegt, die im Explorer nicht zu sehen ist und sich nicht per Datenträgerverwaltung einbinden lässt. Hinzu kommt, dass Sie das Zertifikat zwar in den Eigenschaften der Datei sehen können, dazu aber durch diverse Unterdialoge klicken müssen.

Wir empfehlen daher die Sysinternals-Freeware SigCheck.exe von Microsoft. Damit ermitteln Sie auf einen Schlag das zum Signieren genutzte Zertifikat mitsamt Zertifizierungspfad sowie diverse Prüfsummen.

SigCheck ist ein Kommandozeilenprogramm – das mag zwar abschreckend wirken, aber ohne Kommandozeile gelingt das Prüfen ohnehin nicht. Laden Sie die Freeware über den direkten Download-Link https://download.sysinternals.com/files/Sigcheck.zip herunter. In dem Zip-Archiv stecken drei Varianten, zwei davon für x86-PCs: SigCheck.exe ist für 32-Windows gedacht, enthält aber auch für 64-Bit-Windows die Variante SigCheck64.exe, die es bei Bedarf zur Laufzeit temporär auspackt und nutzt. SigCheck64.exe steckt auch einzeln im Zip-Archiv. SigCheck64a.exe schließlich ist die Version für 64-Bit-ARM-Windows.

Entpacken Sie das SigCheck-Archiv in einen beliebigen Ordner, in dem Sie Schreibrechte haben, etwa D:\Downloads\SigCheck. Wählen Sie des Weiteren einen derzeit freien Laufwerksbuchstaben aus, er wird gleich vorübergehend benötigt, beispielsweise W:. Folgende Befehle verfrachten anschließend alle Infos über den Bootloader in eine Textdatei im SigCheck-Ordner:

MountVol W: /s
D:\Downloads\SigCheck\SigCheck64.exe -i -h W:\EFI\Boot\Bootx64.efi > D:\Downloads\SigCheck\loaderinfo.txt
MountVol W: /d

Passen Sie im ersten und dritten Befehl den Laufwerksbuchstaben sowie im zweiten den Pfad Ihres SigCheck-Ordners an. Den Pfad und den Namen der Textdatei können Sie frei festlegen. Der Name "bootx64.efi" gilt für 64-Bit-Windows auf x86-PCs, bei anderen Architekturen passen Sie den Namen ebenfalls an (32 Bit/x86: bootx86.efi, 64 Bit/Arm: bootaa64.efi). Der Befehl MountVol dient nur dazu, die erwähnte ESP einzubinden.

Die neuen Bootloader

Kennen Sie schon Details zu den neuen Windows-Bootloadern?

Ja, bei unseren ersten Tests (machen Sie das nicht nach, wer weiß, was Microsoft noch alles ändert!) bekamen wir neue Loader installiert. Die Versionsnummer lautete 10.0.26089.1001. Es war dabei egal, ob wir mit Windows 10 oder 11 experimentierten, beide bekamen prüfsummenidentische Bootloader. Verwunderlich ist das nicht, so weit unter der Haube unterscheiden sich Windows 10 und 11 ohnehin nicht. Signiert war der neue Loader bei unseren Tests wie angekündigt mit dem neuen 2023-Windows-Zertifikat, das bis zum 13. Juni 2035 gilt.

BIOS-Änderungen

Wie kann das eigentlich sein, dass Microsoft per Windows-Update am BIOS etwas ändert? Das sollte doch gar nicht möglich sein?

Doch, und das ist auch nicht neu. Auch die meisten alten Legacy-BIOSse ließen sich per Software überschreiben (flashen), also durch eine neue Version ersetzen – und somit verändern. Bloß nutzten sie dazu proprietäre Verfahren des jeweiligen PC- oder BIOS-Herstellers. Beim UEFI-BIOS sind die Methoden zum Überschreiben (UEFI Capsule Update) und zur Modifikation des nichtflüchtigen Konfigurationsspeichers (NVRAM, eigentlich Flash) bloß standardisiert. Außerdem sollten sie durch eine kryptografische Signaturprüfung gegen böswillige Manipulation geschützt sein.

Boot-Blockade per PCIe-Karte

Ein UEFI-BIOS führt doch genau wie das alte Legacy-BIOS noch sogenannte Option-ROMs von PCI-Express-Erweiterungskarten aus, die Firmware etwa für Grafikkarten und RAID-Hostadapter nachrüsten. Kann es dabei auch zu Secure-Boot-Problemen kommen?

Ja. Im Secure-Boot-Modus lädt ein UEFI-BIOS ausschließlich kryptografisch signierte Option-ROMs. Auch deren Signaturen müssen also gültig sein. Wird der zur Prüfung genutzte Schlüssel widerrufen, kann das dazu führen, dass der PC nicht mehr startet oder Funktionen fehlen. Der Hersteller der jeweiligen Erweiterungskarte muss dann ein Firmware-Update mit neuer Signatur nachliefern oder Sie schalten Secure Boot ab.

SigCheck und Linux-Bootloader unter Windows

Auf meinem PC ist neben Windows auch Linux installiert. Wenn ich dessen Bootloader wie von Ihnen beschrieben mit dem Sysinternals-Tool SigCheck.exe prüfe, erscheint: "Verified: Eine Zertifikatskette wurde zwar verarbeitet, endete jedoch mit einem Stammzertifikat, das beim Vertrauensanbieter nicht als vertrauenswürdig gilt." Was ist da los?

Das liegt an einer Gemeinheit von Microsoft. Der Konzern verwendet zum Signieren von Bootloadern zwei verschiedene Zertifikate: Eines ausschließlich für die hauseigenen Windows-Bootloader, eines für alles andere, wozu auch die Linux-Bootloader gehören. Das stört im Alltag meist nicht, weil auf den meisten PCs beide im BIOS stecken.

Aber, und das ist die Gemeinheit: Nur weil üblicherweise beide Zertifikate im BIOS stecken, bedeutet das keineswegs, dass sie auch in Windows enthalten wären. Letzteres bringt nur das für Windows-Bootloader mit. Daher scheitert die Prüfung von Linux-Bootloadern mit SigCheck unter Windows mit dem von Ihnen erlebten Fehlerbild. Prüfen Sie stattdessen unter Linux (Beispiel Ubuntu: sudo sbverify /boot/efi/EFI/ubuntu/shimx64.efi --list). Nur wenn auch dort eine ungültige Signatur moniert wird, gibt es ein Problem. Sonst aber ist sie in Ordnung, auch wenn Windows etwas anderes suggerieren will.

Build-Nummern

SigCheck liest ja auch die Build-Nummer eines Windows-Bootloader aus. Doch geht das nicht einfacher, etwa mit dem Windows-eigenen Programm Winver.exe, das beim Start direkt die Versionsnummer und darin enthalten auch die Build-Nummer nennt?

Nein. Diese Angabe gilt zwar für Windows, aber nicht für den Bootloader. Zur Erinnerung: Microsofts Versionsnummern haben folgenden Aufbau (Beispiel Windows 10): 10.0.19045.4170. Ganz vorn steht die Produktfamilie "10.0", die für Windows 10 und 11 gleichermaßen steht. Dann folgt die Build-Nummer (hier "19045") und dann der Patchlevel (hier "4170"). Der Haken: Der Bootloader kann zwar dieselbe Build-Nummer tragen wie Windows selbst, doch ist das keineswegs die Regel.

Beispiel: Die aktuelle Windows-10-Version 22H2 hat die 19045, der dazugehörige Bootloader hingegen noch die 19041. Windows hatte diese Build-Nummer auch mal, und zwar als Version 2004 (offiziell erschienen 2020 im April). Seitdem sind drei weitere Windows-Versionen veröffentlicht worden (20H2/19042, 21H1/19043 und 21H2/19044), die aber allesamt denselben Bootloader von Version 2004 mitbringen. Er hat seitdem zwar Updates bekommen (zu erkennen am Patchlevel), trägt aber immer noch die alte, sich von Windows unterscheidende Build-Nummer. Wenn Microsoft erst mal die neuen Bootloader (siehe oben) ausspielt, werden sich die Build-Nummern ebenfalls unterscheiden.

Übrigens zeigt auch das Windows-Programm "Systeminformation" (msinfo32.exe) Build-Nummern und Patchlevel, doch auch das sind nicht die des Bootloaders. In der Zeile "Version" steht stattdessen jene von Windows, in "Hardwareabstraktionsebene" die des "Hardware Abstraction Layers" (HAL).

Ein, Aus, Nicht unterstützt

Sie empfahlen, mit msinfo32.exe nachzuprüfen, was in der Zeile "Sicherer Startzustand" steht: "Ein" bedeutet aktives Secure Boot, "Aus" eben das Gegenteil. Bei mir steht aber weder noch, sondern "Nicht unterstützt". Was ist damit gemeint?

Das bedeutet, dass Ihr PC zum Booten Legacy-BIOS-Mechanismen nutzt, also nicht per UEFI startet. Mutmaßlich ist auf Ihrem PC im BIOS-Set-up das CSM aktiviert (Compatibility Support Module). Prüfen können Sie das ebenfalls in msinfo32: Steht in der Zeile "BIOS-Modus" nicht "UEFI", sondern "Vorgängerversion", ist das CSM aktiv. Secure Boot kann in diesem Modus nicht funktionieren, weil Legacy BIOS davon noch nichts wusste. "Nicht unterstützt" steht also für: Secure Boot ist aus, und daran lässt sich ohne das Deaktivieren des CSM sowie die aufwendige Umstellung des Windows-Startmodus auch nichts ändern.

Windows auf MBR-Datenträger

Meine Windows-Installation liegt auf einem Datenträger, der mit dem Partitionsschema MBR eingerichtet ist. Da das Booten per UEFI stattdessen GPT erfordert, kann Secure Boot auf meinem Rechner doch gar nicht an sein, oder?

Sofern der MBR-Datenträger der einzige im PC ist: ja. Falls jedoch mehrere Datenträger vorhanden sind, könnte UEFI und damit Secure Boot trotzdem aktiv sein. Hintergrund: Wenn Windows per UEFI bootet, liegt der Bootloader nicht auf C:, sondern auf der EFI System Partition (ESP). Und nur die ESP muss auf einem Datenträger liegen, der mit GPT eingerichtet ist. Windows selbst, also Laufwerk C:, darf auf einem anderen Datenträger liegen, bei dem es keine Rolle spielt, ob er mit MBR oder GPT eingerichtet ist.

Verlassen Sie sich also nicht auf das Partitionsschema, sondern prüfen Sie besser mit msinfo32.exe, was in der Zeile "Sicherer Startzustand" steht (siehe oben).

Der GPT-Zwang hat übrigens keinen technischen Hintergrund, sondern ist eine willkürliche Entscheidung von Microsoft, die zudem nur für interne Festplatten gilt. Das von einem Stick startende Windows PE etwa kann auch dann im UEFI-Modus booten, wenn der Stick MBR-partitioniert ist.

Vor dem 11. Juli 2023 "veröffentlicht"

In Microsofts Knowledge-Base-Artikel KB5025885 steht (jedenfalls als ich ihn las), dass alle vor dem 11. Juli 2023 veröffentlichten Bootloader unsicher seien. Sie haben zudem darauf hingewiesen, dass die Angabe schwammig ist, weil einer Datei das Veröffentlichungsdatum nicht anzusehen ist. Könnte das Datum gemeint sein, an dem die Datei signiert wurde?

In unserer Sammlung haben wir Windows-Bootloader, die dem widersprechen: Einer mit der Build-Nummer 22621.1702 wurde bereits am 1. Mai 2023 signiert, einer mit 22621.1992 am 6. Juli 2023. Dennoch durften beide bei unseren Tests des ursprünglichen Plans unverändert booten, Windows stufte sie also als sicher ein. Sollte Microsoft beim neuen Plan bleiben, spielt das Signierdatum aber ohnehin keine Rolle mehr, weil ja alle bislang erschienen Bootloader gesperrt werden, egal ob unsicher oder nicht.

Warum 32 Bit?

Bislang dachte ich, dass nur 64-Bit-Windows per UEFI booten kann, in Ihren Artikeln weisen Sie jedoch darauf hin, dass auch 32-Bit-Bootloader gesperrt werden. Kann ich auf meinem per UEFI bootenden PC also neben das 64-Bit-Windows doch das 32-Bit-Pendant installieren?

Nein, es geht um etwas anderes. So wie es Betriebssysteme als 32- und 64-Bit-Varianten geben kann, gibt es diese Varianten auch bei Mainboard-Firmware. Und wenn der PC per UEFI booten soll, müssen Betriebssystem und UEFI-BIOS dieselbe Architektur haben. Ein 64-Bit-Windows startet per UEFI also nur auf Rechnern mit 64-Bit-BIOS, 32-Bit-Windows erfordert analog ein 32-Bit-BIOS. Rechner mit 32-Bit-UEFI-BIOS sind aber sehr selten und heutzutage quasi nicht mehr erhältlich. Dennoch stecken in dafür veröffentlichten Bootloadern Sicherheitslücken, daher tauchen sie nun auch in den Sperrlisten auf.

c’t – Europas größtes IT- und Tech-Magazin

Alle 14 Tage präsentiert Ihnen Deutschlands größte IT-Redaktion aktuelle Tipps, kritische Berichte, aufwendige Tests und tiefgehende Reportagen zu IT-Sicherheit & Datenschutz, Hardware, Software- und App-Entwicklungen, Smart Home und vielem mehr. Unabhängiger Journalismus ist bei c't das A und O.

• c’t-Ausgaben online lesen
• c’t im heise-Shop kaufen

(axv)