Beliebiges Schreiben von Dateien durch Archiv-Extraktion (Zip Slip) in go-rpmutils
20. Juli 2020
0 Min. LesezeitWillkommen beim Snyk Monthly Vulnerability Profile. In dieser Reihe blickt Snyk auf Schwachstellen zurück, die von unserem Security Research Teamentdeckt oder diesem gemeldet wurden. Wir wählen eine bemerkenswerte Schwachstelle aus dem vergangenen Monat aus und erzählen die Geschichte ihrer Entdeckung, Erforschung und Offenlegung. Wir stellen die Forschenden, Entwickler und Nutzer vor, die dabei helfen, Schwachstellen in der Open-Source-Community zu identifizieren und zu beheben.
Diesen Monat betrachten wir eine von mehreren Zip-Slip-Schwachstellen, die Snyks Security Research Team in Golang-Paketen identifiziert hat.
Schwachstelle: Beliebiges Schreiben von Dateien durch Archiv-Extraktion (Zip Slip) Zugewiesene CVEs:CVE-2020-7667Snyk-Analyst: George GkitsasEntdeckt von: Snyk Research Team
Am 5. Juni 2020 veröffentlichte das Snyk Research Team die Details einer Schwachstelle, durch die mittels eines schädlichen ZIP-Archivs beliebige Dateien geschrieben werden konnten. Die Schwachstelle wurde im Golang-Paket go-rpmutils identifiziert. Snyk-Forschende entdeckten sie im Rahmen einer umfassenderen Untersuchung zu Zip-Slip-Schwachstellen im Open-Source-Ökosystem. Der Senior Security Analyst George Gkitsas identifizierte die Schwachstelle zunächst im Paket rpmutils. Schließlich wurde die Schwachstelle dem Paketbetreuer gemeldet, schnell behoben und nach Veröffentlichung der korrigierten Paketversion sowohl in der CVE als auch in der Snyk Vulnerability Database veröffentlicht.
Bevor wir uns mit den Details der Forschung befassen, durch die diese Schwachstelle aufgedeckt wurde, sprechen wir kurz über die Funktionsweise einer Zip-Slip-Schwachstelle. Bei einem Zip-Slip-Angriff wird mithilfe einer speziell präparierten Archivdatei ein Verzeichnis-Traversal ausgenutzt. Wird die Datei mit einer anfälligen Methode entpackt, können Dateien an unbeabsichtigten Speicherorten überschrieben werden. So könnte ein Angreifer Systemdateien überschreiben und letztlich schädliche Befehle remote ausführen oder möglicherweise Fernzugriff auf das System erlangen. Weitere technische Informationen zur Zip-Slip-Schwachstelle und dazu, wie Sie sie verhindern können, finden Sie im Zip-Slip-Spickzettel.
Als Mitglied des Snyk Research Team suchte George nach Mustern, die sich repositoryübergreifend schnell erkennen lassen, um potenziell anfällige Pakete aufzuspüren. Für seine Recherche konzentrierte er sich zunächst auf das Golang-Ökosystem. Das Team wählte für die erste Runde etwa 60 Pakete aus und untersuchte jedes einzelne auf die potenzielle Schwachstelle. Dabei wurden einige falsch-positive Ergebnisse identifiziert, die dem Team halfen, seine Algorithmen besser abzustimmen. Insgesamt wurden durch die Recherche jedoch fünf Schwachstellen entdeckt. Drei davon, darunter das anfällige Paket go-rmputils, erhielten CVEs und wurden in der Snyk Vulnerability Database veröffentlicht. Snyk arbeitet weiterhin mit den Betreuern der beiden anderen anfälligen Pakete zusammen, um sicherzustellen, dass eine Fehlerbehebung verfügbar ist, bevor die Schwachstellen öffentlich bekannt gegeben werden.

Im Fall von go-rpmutils versuchte George nach der Entdeckung und Bestätigung der Ausnutzbarkeit der Schwachstelle, den Paketbetreuer zu kontaktieren. In diesem Fall handelte es sich um die Organisation SAS Software. Die erste Kontaktaufnahme erfolgte per E-Mail an die Adresse, die im Organisationsprofil des Repositorys angegeben war. Obwohl sich diese letztlich als nicht geeignete Adresse für solche Meldungen herausstellte, leitete man Georges Hinweis schnell an eine zuständige Ansprechperson für derartige Offenlegungen weiter. Snyk wurde später darüber informiert, dass SAS Software eine eigene E-Mail-Adresse für Meldungen von Schwachstellen hat. Viele in der Security- und Entwickler-Community betrachten dies als bewährte Praxis.
In jedem Fall reagierte SAS Software während des gesamten Prozesses schnell – die erste Antwort auf die Meldung kam innerhalb weniger Stunden. George arbeitete mit dem Security-Team zusammen, um eine verantwortungsvolle öffentliche Offenlegung der Schwachstelle zu gewährleisten, sobald eine Fehlerbehebung verfügbar war. Das Team des Anbieters lieferte schnell eine Korrektur, die George anschließend testen und als ausreichende Behebung der Schwachstelle bestätigen konnte. Die Schwachstelle wurde schließlich am 5. Juni 2020 veröffentlicht, nur sechs Tage nach der ersten Benachrichtigung des Anbieters.
Dieser Fall ist ein hervorragendes Beispiel für die Zusammenarbeit zwischen Forschenden und Betreuern, wenn sich alle Beteiligten dafür einsetzen, Sicherheitsprobleme verantwortungsvoll und effizient zu beheben. Der Betreuer, in diesem Fall SAS Software, reagierte sehr schnell und ergriff entschlossene Maßnahmen, um das Problem zu lösen. Snyk und SAS Software konnten gemeinsam sicherstellen, dass die Fehlerbehebung das Problem vollständig behob und die Details der Schwachstelle erst nach Bereitstellung einer Korrektur veröffentlicht wurden. Eine wichtige Erkenntnis für die Zukunft: Ein eigener Meldeweg für die Offenlegung von Schwachstellen ist sinnvoll. Sie sollten außerdem dafür sorgen, dass dieser leicht zu finden ist, indem Sie ihn in Ihren README-Dateien veröffentlichen und im Profil Ihres Repositorys angeben.
Snyk möchte sicherstellen, dass Schwachstellen tatsächlich bestehen und ausnutzbar sind, und Paketbetreuern zugleich eine verantwortungsvolle Offenlegung sowie detaillierte Anleitungen zur Behebung ihrer Schwachstellen bieten. Weitere Informationen zu dieser Schwachstelle oder dazu, wie Sie eine in einem Open-Source-Projekt entdeckte Schwachstelle melden können, finden Sie unter den folgenden Links.
Starten Sie mit Capture the Flag
Erfahren Sie in unserem virtuellen On-Demand-Workshop für Einsteiger, wie Sie Capture-the-Flag-Herausforderungen lösen.


