Dateisystem-Schwachstellen in Bootloadern: Ein verstecktes Risiko für Verified-Boot-Mechanismen

In modernen IoT-Systemen, besonders solchen mit Linux-basierten Embedded-Geräten, ist es zunehmend entscheidend geworden, die Integrität und Vertrauenswürdigkeit des Boot-Prozesses sicherzustellen. Verified-Boot-Mechanismen, oft auch Trusted Boot oder Secure Boot genannt, bilden das Fundament der Gerätesicherheit, indem sie garantieren, dass während des Boot-Prozesses nur signierter und authentifizierter Code ausgeführt wird. Dieser Mechanismus ist unverzichtbar, um sensible Funktionen wie Datenverschlüsselung, Authentifizierung und die allgemeine Integrität von IoT-Geräten zu schützen.

Es ist wichtig zu verstehen: Wenn Ihr IoT-System keinen Verified Boot einsetzt, stellen die hier beschriebenen Schwachstellen möglicherweise kein direktes Risiko dar. In solchen Fällen können Angreifer den persistenten Programmcode jederzeit manipulieren, wodurch diese spezifischen Schwachstellen ohnehin irrelevant werden.

Einführung

Der Verified-Boot-Prozess stellt sicher, dass jede Stufe der Boot-Sequenz eines Systems authentifiziert und vertrauenswürdig ist. Grob umrissen umfasst der Prozess die folgenden Schritte:

1. Boot-ROM-Validierung: Das Boot-ROM des System-on-Chip (SoC) leitet den Boot-Prozess ein, indem es einen signierten Bootloader lädt und so die erste Vertrauensschicht schafft.
2. Bootloader-Verifikation: Der Bootloader, üblicherweise U-Boot oder Barebox, lädt kritische Komponenten wie den Linux-Kernel, den Device Tree und das Initramfs aus dem Dateisystem und verifiziert deren Signaturen, um ihre Authentizität sicherzustellen.
3. Ausführung von Linux: Sobald der verifizierte Kernel gebootet ist, führt das System den Anwendungscode aus. Der Linux-Kernel sorgt weiterhin für Sicherheit, indem er die aus dem Dateisystem geladenen Dateien authentifiziert.

Diese Abfolge bildet eine Chain of Trust, in der jede Stufe die Integrität der nächsten verifiziert. Wird ein Teil dieser Kette kompromittiert, könnten Angreifer die Möglichkeit erlangen, beliebigen Code auszuführen, sensible Daten auszulesen oder sich als das Gerät auszugeben. Solche Schwachstellen bergen erhebliche Risiken, denn sie erlauben es Angreifern, bei ausreichendem Zugriff Schadcode auf dem Gerät zu installieren.

Kritische Codepfade

Jeder Schritt in der Chain of Trust verarbeitet und validiert potenziell bösartige Eingaben. So parst das Boot-ROM häufig eine SoC-herstellerspezifische Datenstruktur, die den Bootloader und dessen Signatur enthält. Eine Schwachstelle in diesem Codepfad könnte Angreifern ermöglichen, die Chain of Trust zu umgehen und beliebigen Code auszuführen. Solche Schwachstellen wurden im Boot-ROM bestimmter NXP-SoCs gefunden.

Ein weiterer bekannter kritischer Punkt ist der Bootloader. Je nach Bootloader und Betriebssystem müssen zentrale Dateien wie der Kernel oder Konfigurationsdateien geparst und verifiziert werden. Ein Beispiel für eine Schwachstelle in diesem Bereich ist die berüchtigte BootHole-Lücke im GRUB2-Bootloader, die Systeme erheblichen Sicherheitsrisiken aussetzte.

Dateisystem-Schwachstellen in Bootloadern: Ein verstecktes Risiko

Bootloader wie U-Boot und Barebox sind in IoT-Systemen weit verbreitet, weil sie ausgereift sind, umfangreiche Funktionen bieten und von einer starken Community unterstützt werden. Beide Bootloader verfügen über robuste Mechanismen für Verified Boot, mit denen sie die von ihnen geladenen Dateien authentifizieren können, darunter der Kernel und Konfigurationsdateien.

Ein erstes Audit ihrer Verified-Boot-Implementierungen hat jedoch eine häufig übersehene Schwachstelle zutage gefördert: die Dateisystem-Implementierung selbst.

Dateisysteme als Bedrohungsvektor

Die meisten Bootloader unterstützen eine Reihe von Dateisystemen wie ext4, FAT, SquashFS und UBIFS. Diese Implementierungen sind jedoch oft improvisiert und es fehlen ihnen zentrale Funktionen. Der Hauptgrund dafür ist, dass Bootloader in stark eingeschränkten Umgebungen arbeiten, ohne Unterstützung für Nebenläufigkeit und mit Zugriff auf nur minimale Ressourcen. Vollständige Dateisystem-Implementierungen sind für Bootloader daher überflüssig. Sie müssen lediglich funktional genug sein, um Dateien aus einem Dateisystem zu lesen, mehr nicht.

Eine zentrale Aufgabe einer Dateisystem-Implementierung besteht darin, die auf einem Speichermedium abgelegten Filesystem-Datenstrukturen zu parsen, sinnvoll zu interpretieren und die logischen Dateien an höhere Schichten weiterzureichen. In einem Verified-Boot-Setup mit Bootloadern wie U-Boot oder Barebox werden zwar die Inhalte der Dateien authentifiziert, die Filesystem-Datenstrukturen selbst jedoch typischerweise nicht. Das eröffnet einen Angriffsvektor: Ein Angreifer könnte bösartige Filesystem-Strukturen erstellen, die die Authentifizierungsprüfungen umgehen und Fehler in der Implementierung des Filesystem-Treibers ausnutzen. Durch das Manipulieren von Filesystem-Metadaten können Angreifer die Chain of Trust kompromittieren und so die Ausführung beliebigen Codes oder weitergehende Angriffe ermöglichen.

Wir haben die folgenden Schwachstellen gefunden, die direkt oder indirekt mit den Dateisystem-Implementierungen in den Bootloadern Barebox und U-Boot zusammenhängen:

• CVE-2024-57254: Integer Overflow in U-Boots Funktion zur Berechnung der SquashFS-Symlink-Größe
• CVE-2024-57255: Integer Overflow in U-Boots Funktion zur SquashFS-Symlink-Auflösung
• CVE-2024-57256: Integer Overflow in U-Boots Funktion zur ext4-Symlink-Auflösung
• CVE-2024-57257: Stack Overflow in U-Boots Funktion zur SquashFS-Symlink-Auflösung
• CVE-2024-57258: Mehrere Integer Overflows in U-Boots Speicherallokator
• CVE-2024-57259: Heap-Korruption in U-Boots Funktion zum Auflisten von SquashFS-Verzeichnissen
• CVE-2024-57260: Mehrere Schwachstellen in Bareboxs SquashFS aufgrund fehlender Patches aus Linux
• CVE-2024-57261: Integer Overflow in Bareboxs Speicherallokator
• CVE-2024-57262: Integer Overflow in Bareboxs Funktion zur SquashFS-Symlink-Auflösung

Zum Zeitpunkt der Erstellung dieses Artikels sind alle gefundenen Probleme in Barebox Version v2025.01.0 und U-Boot Version v2025.01-rc1 behoben.

Die Schwachstellen erlauben es einem Angreifer mit Zugriff auf das Speichermedium, Filesystem-Strukturen so zu verändern, dass die Ausführung nicht vertrauenswürdigen Codes möglich wird. Besonders CVE-2024-57256 ist ein lohnendes Ziel, da es einem Angreifer praktisch uneingeschränkten Zugriff auf den Speicher von U-Boot verschafft. Manche mögen die Relevanz von CVE-2024-57257 und CVE-2024-57258 in diesem Angriffsszenario in Frage stellen. Sowohl Barebox als auch U-Boot allozieren Puffer, um Filesystem-Daten zu speichern, wobei sich die Puffergrößen aus den Größenattributen der Filesystem-Strukturen ergeben. Da Angreifer diese Größenattribute manipulieren können, lassen sich Integer Overflows in den Speicherallokatoren auslösen. Das führt zu Buffer Overflows, wenn die Allokatoren weniger Speicher reservieren, als für die kopierten Daten nötig ist.

Auswirkungen dieser Schwachstellen

Die Auswirkungen dieser Schwachstellen hängen von Ihrem Bedrohungsmodell ab und reichen von keine bis kritisch. Wenn Sie keine Verified-Boot-Technologie einsetzen, stellen diese Schwachstellen für Sie voraussichtlich kein Sicherheitsproblem dar. Beruht die Integrität Ihres Produkts jedoch auf Verified-Boot-Mechanismen, könnte ein Angreifer diese Schwachstellen ausnutzen, um die Chain of Trust zu kompromittieren.

Die Lage unter Linux

Man könnte sich fragen, wie die Lage unter Linux aussieht. Ein Fehler in einer Dateisystem-Implementierung wäre unter Linux natürlich ebenfalls problematisch. Die Situation unter Linux ist jedoch aus zwei wesentlichen Gründen im Allgemeinen besser:

• Besseres Testing: Dateisysteme unter Linux werden gründlicher getestet, einschließlich regelmäßigem Fuzz-Testing, was dabei hilft, potenzielle Fehler aufzudecken und zu beheben. AFL-Fuzz-Testing hat viele Fehler in Linux aufgedeckt.
• Verbesserter Schutz: In einem Verified-Boot-Setup werden die vom Linux-Kernel genutzten Dateisysteme typischerweise durch Mechanismen wie dm-verity oder dm-integrity geschützt. Diese sorgen zusätzlich zur Verschlüsselung für die vollständige Integrität des Dateisystems. Ein präpariertes Dateisystem würde dadurch bereits früh auf der Block-Ebene erkannt, was das Risiko einer Ausnutzung mindert.

Fazit

Da sich IoT-Systeme weiter ausbreiten, wird es zunehmend entscheidend, die Integrität des Verified-Boot-Prozesses sicherzustellen. Dateisysteme, in der Chain of Trust oft übersehen, können eine erhebliche Schwachstelle der Bootloader-Sicherheit darstellen. Wir hoffen, dass Dateisystem-Implementierungen in Bootloadern künftig gründlicher getestet werden, um ihre Robustheit und Zuverlässigkeit zu verbessern.