{"id":259382,"date":"2021-11-12T23:34:54","date_gmt":"2021-11-12T22:34:54","guid":{"rendered":"https:\/\/www.borncity.com\/blog\/?p=259382"},"modified":"2022-04-05T15:08:23","modified_gmt":"2022-04-05T13:08:23","slug":"14-schwachstellen-in-busybox","status":"publish","type":"post","link":"https:\/\/borncity.com\/blog\/2021\/11\/12\/14-schwachstellen-in-busybox\/","title":{"rendered":"14 Schwachstellen in BusyBox"},"content":{"rendered":"

\"Sicherheit[English<\/a>]Sicherheitsforscher von JFrog und Claroty Team82 haben 14 Schwachstellen in dem beliebten Tool BusyBox gefunden. Alle Schwachstellen wurden dem Entwicklerder BusyBox vertraulich mitgeteilt und in der am 19. August ver\u00f6ffentlichen Version 1.34.0 behoben,. Die Schwachstellen h\u00e4tten zumindest f\u00fcr einem Denial of Service (DoS) Angriff ausgenutzt werden k\u00f6nnen. In selteneren F\u00e4llen w\u00e4ren jedoch auch Informationslecks und m\u00f6glicherweise Remotecodeausf\u00fchrung m\u00f6glich gewesen.<\/p>\n

<\/p>\n

BusyBox, was ist das?<\/h2>\n

BusyBox<\/a> ist ein 1996 von Bruce Perens geschriebenes Computerprogramm, das verschiedene elementare Standard-Unix-Dienstprogramme vereint. Es l\u00e4uft auf verschiedenen POSIX-Umgebungen wie Linux, Android oder FreeBSD. Viele Werkzeuge sind jedoch so gestaltet, dass sie mit den Schnittstellen eines Linux-Kernels funktionieren. Bruce Perens wollte damals ein auf eine einzelne Diskette passendes, vollst\u00e4ndiges und bootbares Linux-System haben, das sowohl als Rettungssystem, als auch zur Installation eines Debian-Systems verwendbar w\u00e4re. BusyBox wurde entwickelt, um auf eingebetteten Betriebssystemen mit sehr beschr\u00e4nkten Ressourcen arbeiten zu k\u00f6nnen.<\/p>\n

Noch etwas Hintergrund<\/h2>\n

Da viele smarte Ger\u00e4te mit begrenztem Arbeitsspeicher und Speicherressourcen auskommen m\u00fcssen, nutzen diese meist ein Tool wie BusyBox, das von Embedded Linux als eine Art \u201eSchweizer Taschenmesser\" vermarktet wird. Es handelt sich dabei um eine Software-Suite mit vielen n\u00fctzlichen Unix-Hilfsprogrammen, so genannten Applets, die als eine einzige ausf\u00fchrbare 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\u00e4uft auch auf vielen OT- und IoT-Ger\u00e4ten. Au\u00dferdem ist es auf beliebten speicherprogrammierbaren Steuerungen (PLCs), Mensch-Maschine-Schnittstellen (HMIs) und Remote-Terminal-Einheiten (RTUs) zu finden.<\/p>\n

Analyse der BusyBox auf Schwachstellen<\/h2>\n

F\u00fcr die Untersuchung auf Schwachstellen wurde zun\u00e4chst eine manuelle \u00dcberpr\u00fcfung des BusyBox-Quellcodes in einem Top-Down-Ansatz (Verfolgung der Benutzereingaben bis hin zur spezifischen Applet-Verarbeitung) durchgef\u00fchrt. Dabei wurde auch nach offensichtlichen Schwachstellen in Bezug auf logische\/Speicherkorruption gesucht. Der zweite Ansatz war Fuzzing. BusyBox wurde mit Asan<\/a> kompiliert und ein AFL-Harness f\u00fcr jedes BusyBox-Applet implementiert. Jedes Harness wurde anschlie\u00dfend optimiert, indem unn\u00f6tige Teile des Codes entfernt, mehrere Fuzzing-Zyklen auf demselben Prozess ausgef\u00fchrt (persistenter Modus) und mehrere Fuzzing-Instanzen parallel ausgef\u00fchrt wurden.<\/p>\n

Zuerst wurden alle Daemon-Applets dem Fuzzing unterzogen, einschlie\u00dflich HTTP, Telnet, DNS, DHCP, NTP und anderer. Viele Code\u00e4nderungen waren erforderlich, um netzwerkbasierte Eingaben effektiv zu fuzzen. Es wurden f\u00fcr jedes Applet einige Beispiele vorbereitet und Hunderte von gefuzzten BusyBox-Instanzen wurden \u00fcber einige Tage laufen gelassen. Dadurch wurden Zehntausende Abst\u00fcrze generiert, die ausgewertet werden konnten. Daf\u00fcr haben die Sicherheitsforscher ein automatisches Tool entwickelt, das alle Absturzdaten auf der Grundlage des Absturzanalyseberichts klassifiziert, der haupts\u00e4chlich den Stacktrace, die Register und den Assemblercode des betreffenden Codebereichs enth\u00e4lt. Schlie\u00dflich fand eine Untersuchung jedes einzelnen Absturzes statt, mit minimierten Eingabevektor, um die Ursachen zu verstehen, was die Erstellung eines Proof-of-Concept (PoC) erm\u00f6glichte, der die f\u00fcr den Absturz verantwortliche Schwachstelle ausnutzt.<\/p>\n

Zusammenfassend sind die folgenden Schritte in unserer Forschung zu nennen:<\/p>\n

1. \u00dcberpr\u00fcfung des Codes<\/p>\n

2. Fuzzing<\/p>\n

3. Reduktion & Minimierung<\/p>\n

4. Triage<\/p>\n

5. PoC<\/p>\n

6. Testen mehrerer Versionen<\/p>\n

7. Offenlegung<\/p>\n

Bedrohungslandschaft<\/h2>\n

F\u00fcr 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\u00f6ffentlicht, mit der Hoffnung, dass diese Fuzzing-Logiken von der Community weiter verbessert werden k\u00f6nnen, um zuk\u00fcnftig 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\u00fchrbare Version von BusyBox enthielten, die mit einem der betroffenen Applets verkn\u00fcpft war, was zeigt, dass diese Probleme unter Linux-basierten Embedded-Firmware weit verbreitet sind.<\/p>\n

Die Forscher kommen jedoch zu dem Schluss, dass diese Probleme derzeit keine kritische Sicherheitsbedrohung darstellen, weil:<\/p>\n