UEFI Forbidden Signature Database
Sperrliste in der UEFI-Firmware, die kompromittierte oder widerrufene Bootloader-Signaturen und Hashes enthält und damit das Gegenstück zur erlaubten Signaturdatenbank (db) bildet.
Die DBX (Forbidden Signature Database) ist eine der vier Schlüsseldatenbanken im NVRAM eines UEFI-Systems und enthält Signaturen, Zertifikate und Hashes, die beim Start ausdrücklich abgewiesen werden sollen. Während die db (Allowed Database) festlegt, welcher Code als vertrauenswürdig gilt, bildet die dbx das Gegenstück: eine Sperrliste, die selbst dann greift, wenn ein Modul mit einem ansonsten gültigen Schlüssel signiert wurde. Ohne eine gepflegte DBX könnte ein Angreifer einen längst kompromittierten, aber Microsoft-signierten Bootloader nutzen, um an Secure Boot vorbeizukommen.
Verhältnis zu db, KEK und PK
Secure Boot stützt sich auf eine hierarchische Vertrauenskette: Der Platform Key (PK) des Hardwareherstellers autorisiert den Key Exchange Key (KEK), und der KEK wiederum signiert Änderungen an db und dbx. Microsoft besitzt auf den meisten Consumer- und Business-Geräten einen KEK-Eintrag und kann darüber neue Sperrlisteneinträge ausrollen, ohne dass der OEM in jedem Einzelfall eingreifen muss.
| Datenbank | Inhalt | Wirkung |
|---|---|---|
| PK | Plattform-Wurzelschlüssel | Kontrolliert KEK-Einträge |
| KEK | Signaturschlüssel für db/dbx-Updates | Autorisiert Änderungen |
| db | Erlaubte Zertifikate und Hashes | Whitelist für Bootcode |
| dbx | Verbotene Zertifikate und Hashes | Blacklist, hat Vorrang vor db |
Die DBX hat im Konfliktfall Vorrang: Selbst wenn ein Bootloader über die Microsoft UEFI CA in der db als grundsätzlich vertrauenswürdig gilt, blockiert ein passender Hash-Eintrag in der dbx den Start zuverlässig.
Wie Einträge in die DBX gelangen
Auf Windows-Systemen werden DBX-Updates regulär über Windows Update verteilt. Microsoft veröffentlicht regelmäßig konsolidierte Listen, die als signiertes Update-Paket eingespielt und vom UEFI-Loader in den NVRAM geschrieben werden. Linux-Distributionen nutzen das fwupd-Projekt zusammen mit dem Linux Vendor Firmware Service (fwupd.org), der ebenfalls die offiziellen UEFI-Revocation-Lists verteilt. OEMs wie Dell, HPE oder Lenovo liefern parallel Firmware-Updates aus, die bei größeren Vorfällen zusätzliche Einträge oder eine aktualisierte Default-DBX bringen.
In der Praxis finden wir in Assessments regelmäßig Geräte, bei denen die DBX seit Jahren nicht mehr aktualisiert wurde — entweder weil Windows Update auf optionale Firmware-Updates eingeschränkt ist oder weil der OEM-Update-Pfad nie eingerichtet wurde. Für eine Bestandsaufnahme lässt sich der DBX-Stand auf Windows über Get-SecureBootUEFI dbx und auf Linux über mokutil --list-sbat-revocations bzw. die UEFI-Variablen unter /sys/firmware/efi/efivars/ auslesen.
Speicherlimits auf dem Mainboard
Die DBX liegt im SPI-Flash des Mainboards und teilt sich diesen Speicher mit den übrigen UEFI-Variablen. Je nach Plattform stehen für Secure-Boot-Variablen typischerweise nur 32 bis 64 KB zur Verfügung — und mit jeder neuen Sperrliste wächst die DBX. Schon vor Jahren hat das Patchen von Schwachstellen wie BootHole (CVE-2020-10713 in GRUB2) zu spürbarem Verbrauch dieses Speichers geführt, weil dutzende Hash-Einträge gleichzeitig hinzukamen. Auf älteren Mainboards kann ein zu großes DBX-Update fehlschlagen oder im schlimmsten Fall den NVRAM-Bereich überfüllen.
Genau dieses Skalierungsproblem motiviert den Übergang zu einem anderen Modell: dem SBAT-Mechanismus.
SVN- und SBAT-Ansatz als Alternative
Statt jeden einzelnen verwundbaren Bootloader-Hash in die DBX zu schreiben, etabliert sich seit 2022 das Konzept der Secure Version Number (SVN), in der Linux-Welt umgesetzt als SBAT (UEFI Secure Boot Advanced Targeting). Jedes signierte Boot-Modul trägt dabei eine Versionsnummer pro Komponente; in der UEFI-Variable SbatLevel wird die jeweils niedrigste noch akzeptierte Version hinterlegt. Eine einzige Erhöhung dieser Schwelle widerruft sämtliche älteren Versionen auf einen Schlag — ohne pro Build einen DBX-Eintrag zu benötigen.
Microsoft setzt mit der Windows UEFI CA 2023-Migration und CVE-2023-24932 ein vergleichbares Modell um: Die neue Boot-Komponentenkette enthält Versionsinformationen, sodass künftige Revokationen über einen kompakten Schwellenwert statt über zahlreiche Hashes ausgerollt werden können.
Reale Beispiele: BlackLotus und BootHole
Zwei Vorfälle zeigen, wie sehr die DBX in der Praxis benötigt wird. BootHole (CVE-2020-10713) war eine Pufferüberlauf-Schwachstelle in GRUB2, die das Laden beliebigen Codes vor dem Kernel ermöglichte. Da nahezu alle Linux-Distributionen denselben signierten GRUB2-Bootloader nutzten, mussten Microsoft und die Linux-Vendoren dutzende Hashes verwundbarer Versionen in die DBX aufnehmen — verbunden mit dem Risiko, ältere Live-Systeme oder Recovery-Medien unbootbar zu machen.
BlackLotus war 2023 das erste UEFI-Bootkit, das auf vollständig gepatchten Windows-11-Systemen Secure Boot über den Baton-Drop-Bypass (CVE-2022-21894 / CVE-2023-24932) aushebelte. Die Revokation der betroffenen Bootmanager wurde von Microsoft in mehreren Phasen über KB5025885 und Folge-Updates ausgerollt. Die Komplexität dieses Rollouts — und die mehrjährige Übergangszeit — ist direkt eine Folge des Risikos, dass eine zu aggressive DBX-Aktualisierung Geräte unbootbar machen kann.
Risiko: Brick und Dual-Boot-Probleme
Eine fehlerhafte oder zu aggressive DBX kann reale Schäden verursachen. Wenn ein Hash, der für einen aktuell installierten Bootloader gilt, in die Sperrliste aufgenommen wird, startet das Gerät nach dem nächsten Reboot nicht mehr — auf BitLocker-verschlüsselten Systemen mit der Aufforderung zum Recovery Key. Besonders kritisch ist das Szenario auf Dual-Boot-Systemen mit Linux: Wenn der Distributions-Shim oder ältere GRUB-Versionen in die DBX gelangen, kann die Linux-Partition unzugänglich werden, während Windows weiter startet.
Vor jedem manuellen DBX-Update sollten daher der Recovery Key gesichert, ein aktuelles Boot-Medium verfügbar und für Linux-Systeme ein gepflegter shim mit aktuellem SBAT-Level installiert sein. Auf Geräten mit aktiviertem TPM und BitLocker führt eine DBX-Änderung außerdem zu neuen PCR-Messwerten und damit regulär zur Recovery-Aufforderung.
Relevanz für KMUs
Im Mittelstand ist die DBX selten Teil des Patch-Managements — Firmware und Bootkette gelten als „läuft eben". Genau diese Lücke nutzen Bootkit-Kampagnen aus: Ein veralteter DBX-Stand bedeutet, dass öffentlich bekannte Bypass-Bootloader nach wie vor akzeptiert werden, selbst wenn Windows und alle Anwendungen vollständig gepatcht sind. Wer Secure Boot ernst meint, sollte den DBX-Stand zentral inventarisieren, Windows-Update-Richtlinien so konfigurieren, dass Firmware- und Secure-Boot-Updates nicht ausgesetzt werden, und bei Hardwarebeschaffung auf Secured-Core PCs achten — dort werden DBX-Updates und Firmware-Schutzmaßnahmen vom OEM kuratiert ausgeliefert.