exarch: die Symlink-Schwachstelle, die wir gemeldet haben

Ein Archiv zu entpacken wirkt wie die harmloseste Sache der Welt: Man wählt einen Ordner, öffnet das ZIP, und die Dateien landen dort. Aber wenn das Archiv von außen kommt, von einem Benutzer hochgeladen, von einem externen Dienst heruntergeladen, an eine E-Mail angehängt, dann ist die Frage, wohin die Dateien geschrieben werden, eine Sicherheitsfrage. Ein präpariertes Archiv kann versuchen, außerhalb des gewählten Ordners zu schreiben: in Konfigurationsdateien, in Skripte, die der Server beim Start ausführt, in den Ordner eines anderen Benutzers.

exarch ist eine Bibliothek, die genau das verhindern soll. Ihr Kern ist in Rust geschrieben (exarch-core) und wird auch als Python-Paket (exarch) und als Node.js-Paket (exarch-rs) verteilt. Das README stellt sie als sichere Alternative zu Bibliotheken wie tarfile in Python und tar-fs in Node.js vor, die eine lange Geschichte genau solcher Schwachstellen haben. Das zentrale Versprechen ist ein einziges: Die Dateien aus dem Archiv bleiben im Zielordner.

Ab Version 0.6.1 und bis ausschließlich 0.8.0 ließ sich dieses Versprechen umgehen. Das ist der Fehler, den das Advisory GHSA-9r5q-fvpf-p55p beschreibt, veröffentlicht am 2. November 2026 und behoben in exarch 0.8.0. Gemeldet haben wir ihn: Gefunden hat ihn Liam Giannini (Liam-G auf GitHub), ethischer Hacker und Mitgründer von Webcracy. Wir danken dem Maintainer von exarch, der das Problem bestätigt und die Korrektur innerhalb weniger Tage veröffentlicht hat.

Webcracy und IT-Sicherheit

Webcracy macht nicht nur Websites und Anwendungen. IT-Sicherheit ist ein zentraler Teil unserer Arbeit: Penetrationstests, Code-Reviews, Konfigurationsanalysen und Forschung an den Open-Source-Bibliotheken und -Programmen, die wir und unsere Kunden täglich einsetzen. Liam arbeitet als ethischer Hacker: Er sucht Lücken mit denselben Methoden wie ein Angreifer, aber mit dem umgekehrten Ziel. Was er findet, wird vertraulich an diejenigen gemeldet, die es beheben können, und erst veröffentlicht, wenn die Korrektur verfügbar ist. Dieses Vorgehen heißt Responsible Disclosure, und wir haben es auch hier angewendet, wie schon bei der im Oktober gemeldeten Schwachstelle in FreeScout.

Was beim Entpacken passierte

Um das Problem zu verstehen, braucht es zwei Zutaten.

Die erste ist ein symbolischer Link, ein Eintrag im Dateisystem, der sich wie ein Ordner verhält, in Wirklichkeit aber auf einen anderen Ort zeigt. In der Standardkonfiguration lehnt exarch symbolische Links ab, die im Archiv enthalten sind: Das ist einer der klassischen Schutzmechanismen gegen bösartige Archive. Einen anderen Fall berücksichtigte die Bibliothek aber nicht: einen symbolischen Link, der schon vor dem Entpacken im Zielordner liegt. Das kommt häufiger vor, als man denkt: geteilte Ordner, Updates, die über eine bestehende Installation entpackt werden, Umgebungen, in denen uploads oder cache auf eine andere Festplatte zeigen.

Die zweite Zutat ist ein Cache der angelegten Ordner. Um nicht für jede Datei dieselben Prüfungen zu wiederholen, merkte sich exarch, welche Ordner es während des Entpackens bereits angelegt hatte, und betrachtete sie als vertrauenswürdig. Das Problem: Die Rust-Funktion, mit der sie angelegt werden, create_dir_all, meldet auch dann Erfolg, wenn der Pfad bereits existiert und ein symbolischer Link auf einen Ordner ist. exarch vermerkte also als «von mir angelegten Ordner» einen Link, der in Wirklichkeit woandershin führte.

Einem Angreifer genügte ein Archiv mit zwei völlig gewöhnlichen Einträgen: einem Ordner redirect/ und einer Datei redirect/pwned.txt. Existierte im Ziel bereits redirect als Link auf einen beschreibbaren externen Ordner, brachte der erste Eintrag den Link in den Cache der vertrauenswürdigen Ordner. Bei der Validierung des zweiten Eintrags übersprang exarch die Auflösung des übergeordneten Pfads, weil er als vertrauenswürdig galt, und auch die des vollständigen Pfads, weil das Archiv keine symbolischen Links enthielt. Das beim Öffnen verwendete Flag O_NOFOLLOW schützt nur die letzte Komponente des Pfads, nicht die Ordner dazwischen. Ergebnis: Das Entpacken wurde erfolgreich abgeschlossen, und die Datei tauchte in outside/pwned.txt auf, außerhalb des gewählten Ordners, mit dem Inhalt, den der Ersteller des Archivs bestimmt hatte.

Betroffen waren sowohl TAR als auch ZIP, mit der standardmäßigen Sicherheitskonfiguration. Das Entpacken von 7z-Dateien war dagegen nicht verwundbar, weil es den Ordner-Cache bewusst nicht für die Pfadvalidierung nutzte.

Wie schwerwiegend ist das

Die konkreten Auswirkungen hängen davon ab, wo die Anwendung läuft. Im schlimmsten Fall handelt es sich um ein beliebiges Schreiben von Dateien außerhalb des Ziels, begrenzt nur durch die Berechtigungen des Prozesses. Mit der Option skip_duplicates = false, die das Überschreiben erlaubt, konnten auch bestehende Dateien, die über den Link erreichbar waren, gekürzt oder ersetzt werden. Daraus können geänderte Konfigurationen folgen, ein dauerhafter Zugang für den Angreifer, ein Dienstausfall oder die Ausführung von Code, wenn die geschriebene Datei später von einer anderen Komponente gelesen oder ausgeführt wird.

Es gibt allerdings eine notwendige Bedingung: Der symbolische Link muss bereits im Ziel liegen, und der Angreifer muss seinen Namen kennen. Deshalb ist der Schweregrad mittel, in der Kategorie CWE-59, fehlerhafte Auflösung von Links vor dem Dateizugriff. Mittel heißt aber nicht nebensächlich: Der Fehler trifft genau die eine Garantie, derentwegen man sich für eine Bibliothek wie exarch entscheidet.

Wie wir es überprüft haben

Das Problem fiel beim Lesen des Quellcodes von exarch 0.6.1 auf, als wir den Weg eines Archiveintrags vom Ordner-Cache (DirCache) über die Validierung in SafePath bis zum endgültigen Öffnen der Datei verfolgten. Zur Bestätigung schrieb Liam zwei Regressionstests, einen für TAR und einen für ZIP, die das Archiv im Speicher erzeugen und in eigens angelegte temporäre Ordner entpacken, unter Linux mit Rust 1.98.0. Auf der verwundbaren Version schlugen beide Tests fehl, weil das Entpacken gelang und die Datei aus dem Ziel ausbrach.

Zusammen mit der Meldung haben wir auch eine minimale Korrektur vorbereitet: die Zugehörigkeit zum Cache bei der Validierung von TAR und ZIP nicht mehr als Sicherheitsnachweis zu verwenden und beide damit an das anzugleichen, was der 7z-Code bereits tat. Mit dieser Änderung liefen die beiden Regressionstests durch, ebenso wie die bestehenden 801 Unit-Tests und 136 Integrationstests.

Die Korrektur in 0.8.0

Der Maintainer ging über den minimalen Patch hinaus. Im Pull Request #816, enthalten in Version 0.8.0, wurde der Cache entfernt und durch eine Prüfung ersetzt, die für jede geschriebene Datei jede Pfadkomponente unterhalb des Ziels mit lstat untersucht. Der übergeordnete Pfad wird jedes Mal aufgelöst, außer wenn er mit der Wurzel des Ziels übereinstimmt. Die Korrektur gilt für TAR, ZIP und 7z, einschließlich der atomaren Entpackmodi.

Eine Verhaltensänderung sollten Sie kennen: Standardmäßig schlägt das Entpacken jetzt fehl, wenn sich im Ziel irgendein symbolischer Link befindet, auch einer, der innerhalb des Ziels selbst bleibt. Wer sie braucht, kann sie mit der Option für symbolische Links wieder zulassen; dann werden sie nur akzeptiert, wenn sie innerhalb des Zielordners bleiben. Ein symbolischer Link, der selbst als Zielordner dient, bleibt erlaubt.

Der Pull Request benannte offen eine verbleibende Einschränkung: Eine pfadbasierte Prüfung lässt ein Zeitfenster zwischen Überprüfung und Schreiben offen, das jemand ausnutzen kann, der während des Entpackens bereits Schreibzugriff auf das Ziel hat. Version 0.9.0, erschienen am 5. November, enthält neben anderen Änderungen die Verankerung der Schreibvorgänge an Verzeichnis-Deskriptoren, die für diesen Fall empfohlene Lösung. Ein sehr gutes Beispiel dafür, wie eine Meldung zum Anlass werden kann, ein ganzes Subsystem zu härten, statt nur ein einzelnes Loch zu stopfen.

Was tun, wenn Sie exarch verwenden

Wenn Sie exarch-core, das Python-Paket exarch oder das npm-Paket exarch-rs in einer Version vor 0.8.0 verwenden, aktualisieren Sie. Da 0.9.0 weitere Schutzmechanismen beim Schreiben von Dateien hinzufügt, lohnt es sich, direkt auf die neueste verfügbare Version zu gehen und dabei die inkompatiblen API-Änderungen aus den Release Notes zu prüfen. Kontrollieren Sie nach dem Update auch, dass Ihre Entpackvorgänge nicht an legitimen symbolischen Links im Ziel scheitern: Das ist das neue Standardverhalten, und die sicherste Wahl ist, in einen leeren, eigens dafür vorgesehenen Ordner zu entpacken.

Dieser Rat gilt übrigens für jede Entpack-Bibliothek, nicht nur für exarch: Entpacken Sie Archive, die von außen kommen, in einen neuen, leeren Ordner, den Ihr eigener Prozess angelegt hat, mit einem Benutzer, der nur die unbedingt nötigen Berechtigungen hat. Dann findet auch ein Fehler wie dieser keine fertigen Links, die er ausnutzen könnte.

Warum wir Open-Source-Software untersuchen

Ein großer Teil der Software in Unternehmen, auch in solchen, die glauben, keine zu verwenden, besteht aus Open-Source-Bibliotheken wie exarch, oft gepflegt von einer einzelnen Person oder kleinen Gruppen. Der Code ist öffentlich, aber jemand muss ihn mit den Augen dessen lesen, der ihn knacken will. Zeit in die Prüfung dieser Projekte zu investieren und das Gefundene verantwortungsvoll zu melden, ist unser Beitrag, und auch unser Weg, genau zu wissen, was wir für unsere Kunden in Produktion bringen.

Wenn Ihre Anwendung von Benutzern hochgeladene Dateien annimmt, Archive, Dokumente oder Bilder von außen verarbeitet oder einfach noch nie von jemandem angeschaut wurde, der nach Lücken sucht, sprechen wir gerne darüber. Unsere Arbeit im Bereich Penetration Testing beginnt genau hier: Code und Konfiguration lesen, verstehen, wo Daten nicht geprüft werden, und Ihnen präzise sagen, was wir überprüft haben und was nicht.

Sprechen wir über die Sicherheit Ihrer Anwendungen↗