Beliebtes Tool „BusyBox“ unter der Lupe

Sicherheitsforscher von JFrog und Claroty Team82 fanden 14 Schwachstellen in dem beliebten Tool BusyBox. Alle Schwachstellen wurden dem Entwickler gemäß Branchen Best Practices vertraulich mitgeteilt und dem entsprechend von BusyBox in Version 1.34.0 behoben, die am 19. August veröffentlicht wurde.

Die Schwachstellen hätten zumindest zu einem Denial of Service (DoS) führen können. In selteneren Fällen hätten sie jedoch auch zu Informationslecks und möglicherweise zur Remotecodeausführung führen können.

Hintergrund

Da viele smarte Geräte mit begrenztem Arbeitsspeicher und Speicherressourcen auskommen müssen, nutzen diese meist ein Tool wie BusyBox, das von Embedded Linux als eine Art „Schweizer Taschenmesser“ vermarktet wird. Es handelt sich dabei um eine Software-Suite mit vielen nützlichen Unix-Hilfsprogrammen, so genannten Applets, die als eine einzige ausführbare Datei verpackt sind. BusyBox bietet eine vollwertige Shell, einen DHCP-Client/Server und auch kleine Dienstprogramme wie cp, ls, grep und andere und es läuft auch auf vielen OT- und IoT-Geräten. Außerdem ist es auf beliebten speicherprogrammierbaren Steuerungen (PLCs), Mensch-Maschine-Schnittstellen (HMIs) und Remote-Terminal-Einheiten (RTUs) zu finden. 

Methodik der Forschung

Für die Untersuchung wurde zunächst eine manuelle Überprüfung des BusyBox-Quellcodes in einem Top-Down-Ansatz (Verfolgung der Benutzereingaben bis hin zur spezifischen Applet-Verarbeitung) durchgeführt. Dabei wurde auch nach offensichtlichen Schwachstellen in Bezug auf logische/Speicherkorruption gesucht. Der zweite Ansatz war Fuzzing. BusyBox wurde mit Asan kompiliert und ein AFL-Harness für jedes BusyBox-Applet implementiert. Jedes Harness wurde anschließend optimiert, indem unnötige Teile des Codes entfernt, mehrere Fuzzing-Zyklen auf demselben Prozess ausgeführt (persistenter Modus) und mehrere Fuzzing-Instanzen parallel ausgeführt wurden. 

Zuerst wurden alle Daemon-Applets dem Fuzzing unterzogen, einschließlich HTTP, Telnet, DNS, DHCP, NTP und anderer. Viele Codeänderungen waren erforderlich, um netzwerkbasierte Eingaben effektiv zu fuzzen. Es wurden für jedes Applet einige Beispiele vorbereitet und Hunderte von gefuzzten BusyBox-Instanzen wurden über einige Tage laufen gelassen. Dadurch wurden Zehntausende Abstürze generiert, die ausgewertet werden konnten. Dafür haben die Sicherheitsforscher ein automatisches Tool entwickelt, das alle Absturzdaten auf der Grundlage des Absturzanalyseberichts klassifiziert, der hauptsächlich den Stacktrace, die Register und den Assemblercode des betreffenden Codebereichs enthält. Schließlich fand eine Untersuchung jedes einzelnen Absturzes statt, mit minimierten Eingabevektor, um die Ursachen zu verstehen, was die Erstellung eines Proof-of-Concept (PoC) ermöglichte, der die für den Absturz verantwortliche Schwachstelle ausnutzt.

Zusammenfassend sind die folgenden Schritte in unserer Forschung zu nennen: 

1. Überprüfung des Codes
2.  Fuzzing
3. Reduktion & Minimierung 
4. Triage
5. PoC
6. Testen mehrerer Versionen 
7. Offenlegung

Bedrohungslandschaft  

Für die Open-Source-Security- und Cybersecurity-Communities haben JFrog und Claroty einen einfachen Leitfaden erstellt, der beschreibt, wie man BusyBox fuzzt. Der Leitfaden wird zusammen mit allen Fuzzing-Harnessen veröffentlicht, mit der Hoffnung, dass diese Fuzzing-Logiken von der Community weiter verbessert werden können, um zukünftig noch mehr Fehler in BusyBox zu finden und zu beheben.Bei der Untersuchung von JFrogs Firmware-Datenbank mit mehr als 10.000 Embedded-Firmware fanden die Sicherheitsforscher heraus, dass 40 Prozent von ihnen eine ausführbare Version von BusyBox enthielten, die mit einem der betroffenen Applets verknüpft war, was zeigt, dass diese Probleme unter Linux-basierten Embedded-Firmware weit verbreitet sind.

Die Forscher kommen jedoch zu dem Schluss, dass diese Probleme derzeit keine kritische Sicherheitsbedrohung darstellen, weil:

1. Die DoS-Schwachstellen trivial auszunutzen sind, aber die Auswirkungen werden in der Regel durch die Tatsache abgeschwächt, dass Applets fast immer als separater Forked-Prozess ausgeführt werden.
    
2. Die Schwachstelle des Informationslecks ist nicht trivial auszunutzen.
    
3. Die „Use-after-free“-Schwachstellen lassen sich möglicherweise für die entfernte Codeausführung ausnutzen, aber derzeit wurde nicht versucht, einen ausführbaren Exploit für sie zu entwickeln. Darüber hinaus ist es recht selten (und von Natur aus unsicher), ein awk-Muster aus einer externen Eingabe zu verarbeiten.

Obwohl die Schwachstelle im LZMA-Dekomprimierungsalgorithmus gefunden wurde, unterstützen viele Applets eine LZMA-Komprimierung. Das allgegenwärtige ZIP-Format unterstützt beispielsweise die LZMA-Kompression als „Typ 14“-Kompression.

Aus der Sicht eines Angreifers ist ZIP ein viel besserer Angriffsvektor, da:

• unzip-Aufrufe viel gängiger sind als direkte unlzma-Aufrufe.
   
• Es bei diesem Angriffsvektor keine Einschränkungen hinsichtlich des Dateinamens gibt (im Gegensatz zum tar Angriffsvektor, der die .lzma Dateiendung erfordert) 
   
• Die ausgespähten Daten können extrahiert und in Dateien gespeichert werden, die später aus der Ferne gelesen werden können.

Behebungen und Workarounds

Alle 14 Sicherheitslücken wurden in BusyBox 1.34.0 (direkter Download-Link) behoben und die Benutzer werden dringend gebeten, ein Upgrade durchzuführen.Wenn ein Upgrade von BusyBox nicht möglich ist (aufgrund spezifischer Anforderungen an die Versionskompatibilität), können BusyBox 1.33.1 und frühere Versionen ohne die verwundbaren Funktionen (Applets) als Workaround kompiliert werden.

https://jfrog.com/de/