Unsicherer Systemstart: Sicherheitslücke in initramfs erlaubt Umgehung von Linux-Bootschutz

Linux-Distributionen wie Ubuntu und Fedora weisen kritische Schwachstelle beim Startvorgang auf – Angreifer benötigen nur kurzzeitigen physischen Zugriff

Eine Sicherheitslücke in gängigen Linux-Systemen wie Ubuntu und Fedora könnte Angreifern mit physischem Zugriff Tür und Tor öffnen. Der Sicherheitsforscher Alexander Moch vom IT-Sicherheitsunternehmen ERNW hat entdeckt, dass sich trotz aktivierter Schutzmaßnahmen wie Secure Boot, vollständiger Festplattenverschlüsselung und gesperrtem Bootloader ein Umweg über das Initial RAM Filesystem (initramfs) nutzen lässt.

Konkret geht es um eine Debug-Shell, die unter bestimmten Umständen verfügbar wird – beispielsweise, wenn ein Nutzer mehrfach ein falsches Passwort für die verschlüsselte Root-Partition eingibt. Diese Shell gewährt weitreichenden Zugriff auf das System noch vor dem eigentlichen Start des Betriebssystems. Von dort aus lassen sich nicht nur Schutzmaßnahmen umgehen, sondern auch persistente Schadsoftware installieren – etwa durch gezielte Manipulation von Startdateien oder das Einfügen von Backdoors.

„Die Möglichkeit, eine Root-Shell im initramfs zu starten, ist in vielen Distributionen nicht ausreichend abgesichert“, warnt Moch. Dabei handle es sich nicht um ein theoretisches Problem, sondern um ein reales Risiko – insbesondere in Szenarien, in denen Angreifer kurzzeitig physischen Zugang zu einem Gerät erlangen, etwa in Hotelzimmern, Büros oder beim Verlust eines Laptops.

Der Angriff ist überraschend simpel und erfordert lediglich einen USB-Stick sowie grundlegende Kenntnisse über den Linux-Startvorgang. Viele gängige Sicherheitsleitfäden für Linux erwähnen diesen Angriffsvektor nicht oder stufen ihn als vernachlässigbar ein.

Moch appelliert daher an Distributionen und Administratoren, initramfs standardmäßig besser abzusichern – etwa durch vollständige Deaktivierung von Debug-Shells oder zusätzliche Authentifizierungsschritte beim Laden des initramfs.

Selbst scheinbar gut gesicherte Systeme können unerwartete Schwachstellen aufweisen – und der Teufel steckt oft im Detail.

Das Problem: Bei gängigen Distributionen wie Ubuntu oder Fedora lässt sich eine Debug-Shell zuverlässig aktivieren, wenn mehrmals hintereinander ein falsches Passwort für die verschlüsselte Root-Partition eingegeben wird. In dieser Umgebung kann ein Angreifer mit physischem Zugriff das Initial RAM Filesystem (initramfs) manipulieren – etwa durch das Einfügen bösartiger Hooks, die beim nächsten regulären Start des Systems automatisch ausgeführt werden.

Ermöglicht wird dies durch eine grundlegende Schwachstelle im Design: Das initramfs selbst ist in der Regel nicht signiert. Zwar sind Kernel-Image und Kernel-Module kryptografisch geschützt, doch die Manipulation des initramfs – inklusive Entpacken, Modifizieren und erneutem Packen – hat keine Auswirkungen auf deren Signaturen. Angriffe dieser Art hinterlassen somit keine direkten Spuren im signierten Teil des Systems.

Solche Methoden sind nicht völlig neu: Bereits CVE-2016-4484, sowie Werkzeuge wie „EvilAbigail1“ (2015) und „de-LUKS2“ (2018) zeigten ähnliche Schwachstellen auf. Im aktuellen Fall handelt es sich um ein sogenanntes „Evil-Maid“-Szenario – ein Angriff, bei dem ein Angreifer für kurze Zeit physischen Zugriff auf das Gerät hat. Anders als bei früheren Varianten ist hier jedoch keine direkte Manipulation der Festplatte notwendig. Stattdessen folgt der Angriff der normalen Boot-Sequenz, nutzt die Debug-Shell und ein präpariertes USB-Laufwerk, um das initramfs gezielt zu verändern.

Diese Lücke ist weniger ein technisches Versagen der Linux-Distributionen als vielmehr ein blinder Fleck in vielen Sicherheitsrichtlinien. Weder CIS-Benchmarks noch die bekannten STIGs des US-amerikanischen NIST noch das Sicherheitstool Lynis berücksichtigen diesen Angriffsvektor. In vielen Hardening-Guides bleibt der initramfs-Aspekt unerwähnt – obwohl er in Kombination mit physischem Zugriff ein realistisches Bedrohungsszenario darstellt.

Abhilfe könnten künftig sogenannte Unified Kernel Images (UKIs) schaffen, bei denen initramfs und Kernel gemeinsam signiert und als eine monolithische Binärdatei ausgeliefert werden. Auch Trusted Platform Modules (TPMs) bieten Ansätze, das initramfs verlässlich zu messen und Manipulationen zu erkennen. Die Details dieser Lösungen sprengen jedoch den Rahmen dieses Beitrags. Interessierte Leser finden weiterführende Informationen unter anderem in den Analysen „The Strange State of Authenticated Boot and Disk Encryption on Generic Linux Distributions“ und „Brave New Trusted Boot World“.

Was ist initramfs – und warum ist es ein Sicherheitsrisiko?

Alexander Moch erklärt, warum das sogenannte initramfs eine zentrale Rolle im Linux-Startvorgang spielt – und warum es gleichzeitig ein potenzielles Einfallstor für Angreifer darstellt.

Das Initial RAM Filesystem, kurz initramfs, ist ein temporäres Dateisystem, das der Linux-Kernel beim Start entpackt und nutzt, um grundlegende Aufgaben auszuführen, bevor das eigentliche System geladen wird. In einfachen Setups, etwa bei unverschlüsselten Systemen mit Standarddateisystemen wie ext4 auf lokaler Hardware, kann der Kernel unter Umständen direkt die Root-Partition einbinden – initramfs ist dann nicht zwingend notwendig.

Anders sieht es aus, wenn komplexere Startbedingungen vorliegen: Ist etwa die Root-Partition verschlüsselt – was bei sicherheitsbewussten Linux-Nutzern oft der Fall ist – kann der Kernel nicht direkt darauf zugreifen. In diesem Fall übernimmt initramfs eine Schlüsselrolle: Es enthält die notwendigen Kernel-Module und kleine Dienstprogramme aus dem Userspace, um zunächst eine Passwortabfrage bereitzustellen und anschließend die verschlüsselte Partition zu entschlüsseln. Erst danach übergibt initramfs die Kontrolle an das eigentliche Root-Dateisystem.

Warum ist initramfs nicht signiert?

Um eine Vielzahl von Hosts zu unterstützen, wird initramfs nicht vom Distributor, sondern vom Host selbst erstellt. Tools wie dracut enthalten die erforderlichen Kernel-Module und Benutzerraum-Dienstprogramme, sobald eine Aktualisierung dieser Komponenten oder des Kernels verfügbar ist. Daher kann initramfs nicht vom Distributor signiert werden, und die Auslieferung eines generischen, signierten initramfs, das alle möglichen Konfigurationen unterstützt, ist nicht möglich.

Dieses Problem besteht zum Teil deshalb, weil initramfs dynamische Änderungen der Hardware- und Systemkonfiguration berücksichtigen muss. Darüber hinaus legen viele Distributionen Wert auf die Wiederherstellbarkeit des Systems – also den Erhalt des Zugriffs auf eine Debug-Shell im Falle eines Ausfalls –, oft auf Kosten der physischen Sicherheit.

Fazit

Das Vorhandensein einer Debug-Shell im initramfs stellt einen selten diskutierten, aber realen Angriffsvektor dar, insbesondere in Szenarien mit physischem Zugriff, wie z. B. bei „Evil Maid”-Angriffen. Secure Boot, vollständige Festplattenverschlüsselung und Bootloader-Passwörter sind zwar wichtige Schutzmaßnahmen, können jedoch unterlaufen werden, wenn das initramfs nicht signiert und nicht debugbar ist.

Abhilfemaßnahmen sind einfach und effektiv, beispielsweise die Anpassung von Kernel-Parametern, die Einschränkung des Boot-Zugriffs oder die Verwendung einer vollständigen Boot-Partitionsverschlüsselung. Diese fehlen jedoch häufig in Standard-Hardening-Anleitungen, Benchmarks und Tools.

Da Angreifer immer kreativer werden, müssen Verteidiger die Annahmen und blinden Flecken berücksichtigen, die in herkömmlichen Checklisten übersehen werden.

Quelle: ERNW

---