Hinter der Offenlegung: die Zip-Slip-Sicherheitslücke

Im Juni 2018 entdeckte das Snyk-Forschungsteam in verschiedenen Ökosystemen zahlreiche ausnutzbare Fälle der Zip-Slip-Sicherheitslücke, von denen Tausende Anwendungen betroffen waren. Eine so weit verbreitete Sicherheitslücke erfordert einen gut durchdachten vertraulichen Offenlegungsprozess, damit die Verantwortlichen für anfällige Bibliotheken und Projekte vor einer öffentlichen Offenlegung über das Risiko informiert werden. Doch wie kann man eine solche Sicherheitslücke entdecken, beheben und so vielen Betroffenen offenlegen, ohne dass sie öffentlich bekannt wird? In diesem Beitrag erfahren Sie im Detail, wie wir dabei vorgegangen sind – von der Entdeckung über die Offenlegung und das Erstellen von Fix-PRs bis hin zu weiteren Schritten.

Wichtig ist: Zip Slip ist keine konkrete Sicherheitslücke in einem bestimmten Paket oder einer bestimmten Bibliothek, sondern eine Art von Sicherheitslücke, die das beliebige Schreiben von Dateien ermöglicht und in vielen Projekten äußerst verbreitet ist. Außerdem ist Zip Slip an sich keine neue Sicherheitslücke: Diese Art von Schwachstelle gibt es schon seit vielen Jahren, ja sogar Jahrzehnten. Angesichts ihrer Verbreitung und der vielen anfälligen Beispiele, die unser Sicherheitsteam gefunden hat, hielten wir es jedoch für sinnvoll, ihr einen Namen zu geben – ähnlich wie der Zip-Bomben-Sicherheitslücke.

Die Anfänge

Wo könnte man besser anfangen als ganz am Anfang? Anfang 2018 entdeckten wir im Rahmen unserer kontinuierlichen Forschung ein anfälliges Muster beim Umgang von FTP-Clients mit Ordner-Downloads und fanden eine ausnutzbare Implementierung in Apache Hive. Das zeigt, dass eine bekannte Sicherheitslücke, von der FTP-Clients bereits 1990 (und früher) betroffen waren, noch immer in vielen Open-Source-FTP-Client-Bibliotheken in verschiedenen Programmiersprachen besteht. Anschließend fanden wir weitere ähnliche Muster in anderen weit verbreiteten Open-Source-Bibliotheken.

Wir beschlossen, mit dem Entpacken von Archiven zu beginnen. Beim Extrahieren von Dateien aus einem Archiv gibt es einen möglichen Angriffsvektor, der Directory Traversal ermöglicht. Bei einer Directory-Traversal-Sicherheitslücke kann ein Angreifer auf Bereiche des Dateisystems außerhalb des vorgesehenen Zielordners zugreifen. Anschließend kann der Angreifer ausführbare Dateien überschreiben und sie entweder aus der Ferne aufrufen oder warten, bis das System oder ein Benutzer sie startet. So kann er auf dem Gerät des Opfers aus der Ferne Befehle ausführen. Die Sicherheitslücke kann außerdem Schäden verursachen, indem Konfigurationsdateien oder andere sensible Ressourcen überschrieben werden. Sie lässt sich sowohl auf Client-Geräten (Benutzergeräten) als auch auf Servern ausnutzen.

Ausnutzbare Bibliotheken finden

Das Team untersuchte mehrere Codebeispiele aus beliebten Open-Source-Bibliotheken der Java-, JavaScript- und Go-Ökosysteme. Schon nach kurzer Suche stellten wir zu unserer Überraschung fest, dass mehr als die Hälfte davon anfällig war. Das bedeutet: Über die Hälfte der zunächst untersuchten Bibliotheken bereinigte oder validierte keine Dateinamen in Archiven. Wird das ausgenutzt, können beliebige Dateien überschrieben werden. Hier finden Sie die vollständige Liste.

Schon früh wurde deutlich, dass manche Programmiersprachen stärker von dieser Sicherheitslücke betroffen sind als andere, während sie in einigen praktisch nicht vorkommt. Sehen wir uns einige Ökosysteme an und prüfen, wie sich ihre unterschiedlichen Ansätze für die Archivverwaltung auf die Verbreitung der Zip-Slip-Sicherheitslücke auswirkten.

Zip Slip in Java

Die Java-Laufzeitumgebung stellt beispielsweise die Zip-Klassen als Teil der Kernsprache bereit. Damit können Entwickler Code schreiben, der Archive liest und Dateien aus ZIP-Archiven extrahiert. Beliebte Java-Bibliotheken wie Apache Commons-Compress unterstützen weitere Formate, was das Problem noch verbreiteter macht. Es gibt jedoch keine einfache API, die all dies in einem einzigen Aufruf erledigt. Daher gibt es im Ökosystem viele unterschiedliche Implementierungen, von denen die meisten anfällig waren.

Zip Slip in Python

Python hingegen stellt über die Kernlaufzeit die Klasse zipfile bereit ((zipfile.extractall())) und ist nicht anfällig. Deshalb fanden wir bei der Analyse von Python-Repositories immer wieder sichere Implementierungen.

Bemerkenswert ist, dass Pythons tarfile weiterhin betroffen ist. Der Grund: Die Implementierung in der Kernlaufzeit ist anfällig. Befindet sich eine Sicherheitslücke in der Kernlaufzeit einer Programmiersprache statt in einer Bibliothek, kann sie automatisch behoben werden, sobald eine Anwendung auf eine neuere Sprachversion aktualisiert wird – ganz ohne Änderungen an der Anwendung oder ihren Abhängigkeiten. Das kommt oft häufiger vor, als dass Entwickler auf eine neuere Abhängigkeitsversion aktualisieren – es sei denn, Sie verwenden ein Tool wie Snyk, das Sie dabei unterstützt! (Entschuldigung, ich konnte mir diesen schamlosen Werbehinweis nicht verkneifen!)

Wer ist noch betroffen?

Es zeigte sich bald, wie stark einige der Kernsprachen und Bibliotheken betroffen waren. Deshalb konzentrierten wir uns auf Open-Source-Projekte, die keine Bibliotheken waren. Wir scannten die beliebtesten Open-Source-Java-Projekte auf GitHub, die Code zur Archivverarbeitung enthielten.

Schnell bemerkten wir, dass die meisten Implementierungen die Sicherheitslücke enthielten. Am häufigsten war dies bei Java der Fall, wo wir immer wieder dieselben anfälligen Implementierungen fanden. Das deutete darauf hin, dass diese anfälligen Codeausschnitte aus anderen Projekten, Dokumentationen oder Communities übernommen wurden.

StackOverflow: der Marktplatz für Sicherheitslücken

Als wir die größte Entwicklerressource für Entwickler untersuchten, die Code per Copy-and-paste übernehmen, wurde schnell klar: Unsere Vermutung stimmte. Wir fanden viele Fragen dazu, wie man Dateien am besten programmgesteuert aus Archiven extrahiert. Außerdem stellten wir fest, dass fast alle Antworten auf StackOverflow anfällig waren. Besonders besorgniserregend: Alle anfälligen Antworten hatten mehr Upvotes, als man mit einem sicherheitsförmigen Stock schütteln konnte. Hier sind einige unserer Favoriten, darunter ein paar Kommentare, die uns den Tag versüßt haben:

• „Utility zum Entpacken eines ganzen Archivs in ein Verzeichnis in Java“ Wir schreiben doch inzwischen das Jahr 2011, und es gibt nicht einmal eine (gängige) Drittanbieterbibliothek, mit der sich ein ZIP-Archiv in Java mit einem einzigen Aufruf entpacken lässt? WTF

• Was ist eine gute Java-Bibliothek zum Packen und Entpacken von Dateien? Na gut, dann sollte die Bibliothek eben sowohl Dateien als auch Streams unterstützen. Es ist reine Zeitverschwendung für alle – für mich, Sie, den Fragesteller und alle anderen, die bei Google darauf stoßen –, wenn wir alle unsere eigenen Zip-Dienstprogramme implementieren müssen. So wie es DRY gibt, gibt es auch DROP: Don’t Repeat Other People.

• Wie lassen sich Dateien in Android programmgesteuert entpacken?

Nachdem wir mit der vertraulichen Offenlegung begonnen hatten, setzte unser Sicherheitsteam die Recherche fort und fand weitere Beispiele für diese Sicherheitslücke. Hier sind einige wichtige Zahlen zu unseren Ergebnissen:

• 12 anfällige Bibliotheken. 5 Fix-PRs erstellt, die zusammengeführt wurden.

• 5 Bibliotheken ohne API auf hoher Abstraktionsebene.

• Tausende Apps mit der anfälligen Implementierung (nicht unbedingt ausnutzbar).

Ist es falsch, sich zu freuen?

Die Aufgabe von Sicherheitsforschern besteht darin, Sicherheitslücken aufzuspüren, Sicherheitslöcher zu schließen und dazu beizutragen, die Softwarewelt zu einem sicheren Ort zu machen – einem Ort, an dem Milliarden Menschen darauf vertrauen können, dass wichtige Geschäftstransaktionen Tag für Tag und Sekunde für Sekunde reibungslos ablaufen. Das heißt nicht, dass es nicht befriedigend ist, eine kritische Sicherheitslücke zu finden. Die gelegentlichen Heureka-Momente sorgen für den präzisen Fokus, den man in den weniger aufregenden Phasen braucht. Das Wissen, dass gleich um die Ecke ein spannender Fund oder ein Sicherheitsrisiko warten könnte, motiviert dazu, Tage, Wochen und Monate lang zu suchen. Eine Sicherheitslücke zu finden, ist ähnlich berauschend wie für Entwickler der Moment, in dem sie endlich die Ursache eines komplexen Fehlers entdecken. Oder eine Anwendung so umgestalten, dass sich ihre Leistung verdoppelt oder ihre Skalierbarkeit verdreifacht.

Als wir den ersten Fall der Zip-Slip-Sicherheitslücke in einem großen Projekt entdeckten, war das sehr aufregend. Das war unser Heureka-Moment. Als wir jedoch feststellten, dass fast jede andere Anwendung eine anfällige Implementierung hatte, waren wir äußerst überrascht. Uns wurde klar, dass diese Sicherheitslücke nicht nur einige wenige Apps betraf, sondern zahlreiche Projekte in verschiedenen Ökosystemen.

Die Daten zu durchforsten und zu verstehen, warum bestimmte Programmiersprachen stärker betroffen waren und wie sich anfällige Codeausschnitte in Open-Source-Projekten verbreiteten, war spannend und aufschlussreich. Es war auch eine völlig andere Art von Recherche als die Suche nach Sicherheitslücken. Die eigentliche Arbeit begann mit der Offenlegung und der Unterstützung der Projekte bei der Behebung des anfälligen Codes: Eine Schwachstelle zu finden ist vergleichsweise einfach, doch alle Verbindungen zu stärken ist schwierig.

Die Offenlegung

Wir hielten uns an den Prozess der verantwortungsvollen Offenlegung und legten den 5. Juni als Datum für die öffentliche Bekanntgabe fest. So hatten die Projektverantwortlichen 60 Tage Zeit, die Probleme zu beheben. Da alle von uns gefundenen anfälligen Projekte Open Source waren, sind auch Aktivitäten im Repository wie Commits und Pull Requests öffentlich und sichtbar. Deshalb galt es, eine angemessene Frist für die Behebung der Probleme gegen das Risiko abzuwägen, sie einer breiten Öffentlichkeit bekannt zu machen und dadurch ungepatchte Projekte zu gefährden.

Als Erstes wandten wir uns an die Verantwortlichen der am weitesten verbreiteten Bibliotheken mit der Sicherheitslücke, um sie darüber zu informieren. In der ersten E-Mail-Runde schrieben wir insgesamt zehn Bibliotheken an. Manche wussten nicht einmal, dass die Bibliothek, die sie einst für den eigenen Bedarf geschrieben hatten, zu einer der beliebtesten Bibliotheken zum Entpacken geworden war. Von den zehn Verantwortlichen baten fünf um Hilfe bei der Behebung des Problems. Daraufhin eröffneten wir Pull Requests mit Fixes (plexus archiver, mholt/archiver, adm-zip, unzipper und zip4j).

Nach der Kontaktaufnahme mit den Verantwortlichen der Bibliotheken wandten wir uns den betroffenen Projekten zu, die ihre eigene Extraktionslogik implementiert hatten, statt eine zentrale Bibliothek zu verwenden. Dieser Code war wahrscheinlich von Grund auf neu geschrieben oder aus Dokumentationen, StackOverflow oder anderen OSS-Projekten kopiert worden. In allen Fällen konnte sich so anfälliger Code weiterverbreiten. Als wir eine Liste erstellt hatten, wurde schnell klar, dass es zu viele Projekte waren, um sie zu kontaktieren, ohne eine öffentliche Bekanntgabe zu riskieren – sei es durch Projekt-Fixes oder durch einzelne Verantwortungslose, die die Informationen ohne Verständnis für die Folgen weitergegeben hätten. Zunächst konzentrierten wir uns auf die großen Projekte und begannen mit Apache, wo 15 Projekte anfällige Implementierungen enthielten.

Nach einem Gespräch mit Mark J Cox, einem Gründungsmitglied der Apache Software Foundation und Leiter des Apache-Sicherheitsteams, erstellten wir eine gemeinsame Tabelle mit allen möglicherweise betroffenen Projekten. So konnten die Verantwortlichen sie intern bewerten und feststellen, welche davon ausnutzbar waren. Unabhängig davon, ob sie ausnutzbar waren, ist es gute Praxis, die anfällige Implementierung zu beheben – und fast alle taten dies, um das Risiko zu vermeiden, dass sie künftig ausgenutzt oder in andere Projekte kopiert würde. Apache Hadoop, Storm, Hive, Maven und Ant waren betroffen. Zum Zeitpunkt der öffentlichen Bekanntgabe wurden öffentliche CVEs (CVE-2018-8008, CVE-2018-8009) erstellt. Außerdem gab es eine Ankündigung zu Maven Zip Slip auf der Apache-Website. Mark arbeitete äußerst kooperativ mit uns zusammen und half dabei, das Problem in den betroffenen Apache-Projekten aufzudecken, zu beheben und zu kommunizieren.

Wir wandten uns auch an Pivotal (die Zip-Integration wurde innerhalb von zwei Tagen nach der Offenlegung behoben!), Oracle, Google, den OWASP Dependency-Check (innerhalb eines Tages nach der Offenlegung behoben!) und viele weitere.

Abschließend wollten wir alle anderen betroffenen Projekte vertraulich informieren. Da es zu viele Projekte waren, um sie von einem einzelnen Team manuell zu testen und zu bewerten, haben wir den Prozess automatisiert: Wir informierten die Maintainer über das mögliche Risiko und baten sie, selbst zu prüfen, ob ihr Projekt tatsächlich ausnutzbar ist. Eine Offenlegung in diesem größeren Umfang birgt natürlich das zusätzliche Risiko, öffentliche Aufmerksamkeit zu erregen. Eines der nicht verwundbaren Projekte wandte sich an Twitter. Daraufhin waren weitere private Gespräche nötig, damit der Beitrag entfernt wurde.

Über die öffentliche Offenlegung hinaus

Als das Problem öffentlich wurde, veröffentlichten wir eine informativen Seite mit Beispielen für verwundbare Anwendungen, Lösungsvorschlägen und mehr. Wir erstellten ein kollaboratives GitHub-Repository, in dem die Community nachsehen kann, welche Bibliotheken und Projekte betroffen sind, und außerdem weitere Bibliotheken und Projekte ergänzen kann, die wir nicht berücksichtigt hatten. Im vergangenen Monat wurden mehrere Bibliotheken und Projekte hinzugefügt, darunter closure, sharpziplib, quazip und andere.

Wenn Sie mehr über die Offenlegung von Zip Slip erfahren möchten, weitere Ratschläge zur Offenlegung benötigen oder Snyk bei einer vertraulichen Offenlegung helfen soll, schreiben Sie an security@snyk.io. Wir helfen Ihnen gerne dabei, Open Source sicherer zu machen – Commit für Commit.