Secure Boot, normalerweise eine unüberwindbare Barriere beim Starten moderner Rechner, hat eine lange bestehende Sicherheitslücke offengelegt. Elf von Microsoft signierte, aber nie widerrufene UEFI-Shims ermöglichen es Benutzern, dieses System zu umgehen. Die Bedrohung betrifft nicht nur Windows und Linux, sondern nahezu alle PCs, die dem Zertifikat von 2011 vertrauen.
Diese von älteren Versionen übernommenen Bootloader werden von der UEFI-Firmware weiterhin akzeptiert. Das Kopieren einer dieser Binärdateien auf die EFI-Partition genügt, um die Secure-Boot-Verifizierung zu umgehen. Im Folgenden erfahren Sie, was Sie wissen müssen, um diese Sicherheitslücke zu verstehen und ihr entgegenzuwirken.
Dieses Sicherheitsproblem wirft Zweifel an dem Vertrauen auf, das dem bekannten „Microsoft Corporation UEFI CA 2011-Zertifikat“ entgegengebracht wurde. Die entscheidende Überwachung des Systemstarts wurde durch ein anhaltendes Versäumnis beeinträchtigt.
Warum stellen diese UEFI-Shims im Jahr 2026 ein großes Risiko für Secure Boot dar?
Secure Boot überprüft beim Systemstart jede geladene Komponente anhand der Listen „db“ (autorisiert) und „dbx“ (gesperrt). Microsoft signiert die Shims mit seinem Zertifikat, das von den meisten Herstellern in die Datenbankdatei eingebettet wird. Soweit so gut.
Der Haken: Ein Shim wird nur einmal signiert und gewährleistet so die Vertrauenskette für nachfolgende Komponenten wie GRUB2 oder den Linux-Kernel. Dadurch entfällt für Microsoft die Notwendigkeit, jedes Update zu signieren. Clever, aber ein zweischneidiges Schwert!
Shims hat vor Jahren unterschrieben, nie widerrufen.
Diese Bootloader stammen alle aus der Zeit vor Version 1.0 (0.7 bis 0.9) und sind mit verschiedenen Lösungen verknüpft. Zu den betroffenen Systemen gehören kommerzielle Linux-Distributionen wie Red Hat Enterprise Linux 7.2, CentOS 7.2, Oracle Linux 7.2 und ROSA Linux. Auch zwei ältere openSUSE-Binärdateien sind betroffen.
Weitere Software, wie beispielsweise PC-Doctor Service Center, baramundi Management Suite, Abitti für das finnische Bildungssystem sowie WipeDrive und Spyrus WTGCreator, sind ebenfalls auf dieser Liste. Sie alle verwenden diese veraltete Signatur, die nie für ungültig erklärt wurde.
Das Kopieren eines signierten Shims auf die EFI-Bootpartition ist technisch gesehen gleichbedeutend damit, einen Generalschlüssel in das Schloss einzuführen und so jeglichen nachgelagerten Hochleistungsschutz zu umgehen.
Wie ermöglichen diese alten Unterlegscheiben das Umgehen von Secure Boot?
Das Hauptproblem besteht darin, dass kein neuer Schadcode benötigt wird. Es genügt, eine zuvor von Microsoft signierte, gültige Shim-Datei zu kopieren und einzufügen. Unabhängig vom Zielsystem, ob Windows oder Linux, wird diese in der Vertrauenskette als legitim akzeptiert.
Um die Sicherheitslücke auszunutzen, benötigt ein Angreifer tatsächlich privilegierten Zugriff auf das System. Dadurch wird die dauerhafte Einschleusung jedoch sehr einfach, da er die schädliche Software installieren kann, ohne dass das UEFI reagiert.
Die Analogie zu BYOVD (Bring Your Own Vulnerable Driver – Bring deinen eigenen, anfälligen Fahrer mit) ist hier treffend. Das Vertrauen in den Shim wird zur Schwachstelle, die durch diese Methode ausgenutzt werden kann.
Konkrete Beispiele veranschaulichen die Auswirkungen veralteter Unterlegscheiben.
Der Oracle Linux 7.2 Shim ermöglicht beispielsweise die Verwendung einer GRUB 2-Version des Oracle Linux 7.1 ISO-Images, das von CVE-2015-5281 betroffen ist. Dies erlaubt die Ausführung beliebigen Codes ohne gründliche Überprüfung. Eine Speicherbeschädigung muss nicht ausgenutzt werden.
Abitti 0.8 kopiert einen Shim, der MokListX, die in Version 0.9 integrierte Sperrliste, ignoriert und somit eine weitere Angriffsfläche bietet. Red Hat Enterprise Linux 7.2 verwendet einen Shim aus der Zeit vor Version 15.3 (der Einführung von SBAT), der die SbatLevel-Richtlinie nicht prüft und gesperrte Images ohne Weiteres lädt.
Dies sind alles Beispiele dafür, wie die vermeintlich unantastbare Vertrauenskette ohne heroische Anstrengung bricht, einfach aufgrund einer vergessenen Komponente.
Was kann getan werden, um sich vor dieser Secure-Boot-Schwachstelle zu schützen?
Die wichtigste Empfehlung ist die Anwendung der neuesten UEFI-Sperrlisten von Microsoft, die seit Juni 2026 verfügbar sind. Diese Aktualisierungen korrigieren die dbx-Datenbank, um diese alten signierten Shims als unerwünscht zu kennzeichnen.
Unter Windows werden diese Updates primär über Windows Update bereitgestellt. Ein kleines PowerShell-Skript von ESET kann verwendet werden, um zu überprüfen, ob die Widerrufe korrekt angewendet wurden. Ein einfacher Test anhand der Hashwerte der fehlerhaften Shims bestätigt den Systemstatus.
Unter Linux werden Datenbankaktualisierungen vom Linux-Hersteller-Firmware-Dienst (LVFS) verwaltet. Das Skript uefi-dbx-audit prüft das lokale System. Es wird empfohlen, die Datenbank vor der Anwendung von DBX-Widerrufen zu aktualisieren, um Inkonsistenzen zu vermeiden.
Eine Frage der Wachsamkeit und Aktualisierung
Dieser Fall verdeutlicht, dass die Sicherheit von Startups nicht nur von der Gültigkeit von Zertifikaten abhängt, sondern auch von der konsequenten Entfernung veralteter Komponenten. Das Ablaufdatum des Microsoft-Zertifikats im Juni 2026 ist irrelevant, wenn die Entfernung nicht wirksam erfolgt.
Der ESET-Bericht hebt hervor, dass mehrere schwerwiegende Bedrohungen, wie beispielsweise die Bootkits BlackLotus und Bootkitty, diesen Sicherheitsvektor ausnutzen könnten. Prävention ist daher unerlässlich und für kritische Infrastrukturen von entscheidender Bedeutung.
Wer glaubt, Secure Boot sei unverwundbar, setzt sich selbst einem Risiko aus. In Sachen Sicherheit ist es ratsam, wie ein guter Bauer vorzugehen: Schwachstellen im Zaun erkennen, bevor der Wolf hindurchkommt.