Auf rund 200.000 Framework-Geraeten mit Linux wurde eine legitim signierte UEFI-Shell ausgeliefert, die den Befehl memory modify (mm) enthaelt. Laut Sicherheitsforschern von Eclypsium kann dieser Befehl missbraucht werden, um Secure Boot zu umgehen und persistente Bootkits zu laden. Der Hersteller hat die Schwachstelle bestaetigt und arbeitet an Updates; Nutzern wird geraten, Firmware-Patches zeitnah einzuspielen und physischen Zugriff zu begrenzen.
Kern der Schwachstelle: privilegierte Funktionen in signierter UEFI-Shell
Die UEFI-Shell dient als low-level Diagnoseumgebung und wird in manchen Builds signiert, damit sie unter Secure Boot lauffaehig ist. In der betroffenen Konfiguration ist der Befehl mm enthalten, der direkten Lese-/Schreibzugriff auf den Systemspeicher gewaehrt. Damit koennen Angreifer kritische Datenstrukturen manipulieren – darunter die Variable gSecurity2, die an der Signaturpruefung von UEFI-Komponenten beteiligt ist.
Folgen fuer die Vertrauenskette von Secure Boot
Secure Boot erzwingt eine Chain of Trust, in der nur signierte und vertrauenswuerdige Komponenten im Pre-Boot-Prozess ausgefuehrt werden. Wird die Variable gSecurity2 gezielt manipuliert – etwa so, dass Pruefungen effektiv ausgesetzt sind –, koennen unsignierte oder boesartige Module im fruehesten Bootstadium geladen werden. Das eroeffnet Bootkits die Moeglichkeit, sich dauerhaft zu verankern, oft ueber Reboots und sogar Neuinstallationen des OS hinweg (vgl. MITRE ATT&CK T1542.003 Pre-OS Boot: Bootkit).
Betroffene Geraete und Einordnung der Ursache
Eclypsium schaetzt, dass etwa 200.000 Framework-Systeme betroffen sind. Wichtig: Es handelt sich nicht um eine kompromittierte Lieferkette, sondern um einen Konfigurationsfehler in der ausgelieferten UEFI-Shell. Framework hat Gegenmassnahmen angekuendigt und rollt Korrekturen schrittweise aus.
Angriffsoberflaeche und realistische Szenarien
Voraussetzung fuer den Missbrauch ist die Ausfuehrung der UEFI-Shell auf dem Zielgeraet. Gelingt dies, kann der mm-Befehl genutzt werden, um Speicherstrukturen zu aendern und Signaturpruefungen auszuhebeln. Laut Eclypsium lassen sich diese Schritte ueber UEFI-Autostart-Skripte automatisieren, wodurch die Persistenz der Malware zusaetzlich steigt. Besonders riskant sind Szenarien mit physischem Zugriff oder moeglicher Bootfaehigkeit von externen Medien.
Empfohlene Gegenmassnahmen und Härtung
Firmware-/BIOS-/UEFI-Updates zeitnah installieren: Die von Framework bereitgestellten Patches adressieren die unsichere Shell-Konfiguration und reduzieren das Risiko der Secure-Boot-Umgehung.
Physische Angriffswege minimieren: Starke UEFI-/BIOS-Passwoerter setzen, Boot von externen Medien unterbinden und die Bootreihenfolge absichern. Diese Huerden erschweren die Initialisierung der UEFI-Shell durch Unbefugte.
UEFI-Shell deaktivieren oder einschränken: Falls in der Firmware-Konfiguration moeglich, die Shell abschalten oder die Ausfuehrung nicht autorisierter UEFI-Treiber und -Anwendungen verhindern.
Vorlaeufige Hersteller-Schluessel entfernen: Das Entfernen des Framework-spezifischen DB-Schluessels in der UEFI-DB kann kurzfristig verhindern, dass signierte Shell-Komponenten starten. Diese Massnahme kann Kompatibilitaet beeinflussen und sollte nach Einspielen der Updates rueckgaengig gemacht werden.
Monitoring und Verifikation der Boot-Integritaet
Organisationen sollten Secure-Boot-Policies und Boot-Events ueberwachen, TPM-basierte Messungen sowie Measured Boot-Protokolle regelmaessig pruefen und die UEFI-Konfiguration auf unautorisierte Aenderungen kontrollieren. Diese Praktiken entsprechen bewährten Leitlinien (z. B. NIST SP 800‑147B) und helfen, Pre-Boot-Manipulationen fruehzeitig zu erkennen.
Der Vorfall zeigt, dass legitime Diagnosewerkzeuge im Pre-Boot-Kontext zu Single Points of Failure in der Secure-Boot-Modellierung werden koennen. Wer Updates zuegig einspielt, den Startpfad restriktiv konfiguriert und die Systemintegritaet kontinuierlich ueberwacht, reduziert das Risiko langlebiger Bootkit-Infektionen signifikant. Betroffene sollten die von Framework veroeffentlichten Firmware-Patches priorisieren und bis dahin strikte Zugriffskontrollen und Logging einsetzen.
