In der in der Programmiersprache Rust geschriebenen Bibliothek async-tar, die Funktionen zum Lesen und Schreiben von Tar-Archiven bereitstellt, wurde eine Schwachstelle (CVE-2025-62518, Codename TARmageddon) entdeckt, die es ermöglicht, beim Entpacken eines speziell gestalteten Tar-Archivs nicht nur die darin enthaltenen Dateien zu extrahieren, sondern auch Dateien, die in einem verschachtelten Tar-Archiv enthalten sind. Diese Schwachstelle kann genutzt werden, um Verifizierungssysteme für Archive zu umgehen und Dateien zu entpacken, für die keine Überprüfung erfolgte.
Die Schwachstelle zeigt sich auch in Forks der Bibliothek async-tar, wie tokio-tar, krata-tokio-tar und astral-tokio-tar, sowie in darauf basierenden Tools, wie dem Paketmanager uv, der als leistungsstarke Alternative zu "pip" für Python-Projekte entwickelt wird. Zu den bekannten Projekten, die verletzliche Bibliotheken nutzen, gehören auch das Testcontainers-Toolkit zum Ausführen von Docker-Containern und die WebAssembly-Laufzeit wasmCloud. Im Repository crates.is verzeichnet die Bibliothek async-tar in den letzten 90 Tagen 1,3 Millionen Downloads, tokio-tar 2,2 Millionen, testcontainers 2,9 Millionen.
Die Schwachstelle wird durch eine fehlerhafte Positionswahl bei der Analyse verschiedener Größenwerte in den ustar- und PAX-Headern verursacht. In Tar-Archiven im PAX-Format werden für jede Datei innerhalb des Archivs zwei Header angegeben - der klassische ustar-Header und der erweiterte PAX-Header. Das Problem entsteht, weil die verletzlichen Bibliotheken beim Entpacken der Dateien anstelle der Berechnung des Offsets basierend auf der Größe aus dem erweiterten PAX-Header die Größe aus dem veralteten ustar-Header verwendeten. Bei einem Nullwert in der Größe im ustar-Header wurde der nachfolgende Dateiinhalte als korrekter TAR-Headerblock für die nächste Datei behandelt.
Um einen Angriff durchzuführen, genügt es, ein TAR-Archiv zu erstellen, in dem im ustar-Header eine Nullgröße angegeben ist, während im Header für das PAX-Format die aktuelle Größe angegeben ist. Dadurch wird der Inhalt der Datei eines anderen Tar-Archivs als Teil des Hauptarchivs behandelt. Ein Beispielcode zum Erstellen solcher Archive ist auf GitHub verfügbar. Die Schwachstelle wurde in den Versionen tokio-tar 0.5.6 und uv 0.9.5 behoben. Für die anderen Bibliotheken wurden bisher keine Patches veröffentlicht, aber für astral-tokio-tar, async-tar und krata-tokio-tar wurden separate Patches vorbereitet.
Die Schwachstelle in den Bibliotheken wurde ein Gefahrenlevel von 8,1 von 10 zugewiesen, da das Problem verwendet werden kann, um entpackte Dateien zu überschreiben (in den verletzlichen Implementierungen werden nicht die Dateien entpackt, die im Archiv sichtbar waren). Dabei wurde die Schwachstelle im Paketmanager uv als unbedenklich eingestuft, da es keinen Sinn macht, den Angriff zu komplizieren und die Schwachstelle durch ein verschachteltes Archiv auszunutzen, wenn die Ausführung von Code direkt über die Build-Skripte im Hauptarchiv erreicht werden kann.
Die Forscher, die die Schwachstelle entdeckt haben, schlugen mehrere hypothetische Angriffsszenarien vor, die es ermöglichen, sicherheitsüberprüfungen zu umgehen und die Ausführung von Code durch Ersetzen von Konfigurationsdateien oder Eingriffe in den Build-Prozess zu erreichen. Es wird angenommen, dass das eingesandte Archiv die automatisierte Prüfung eines Sicherheitsscanners und eine manuelle Prüfung bestehen kann, während der Prüfer möglicherweise nicht auf ein seltsames verschachteltes Archiv mit anderen Dateien achtet, wodurch beim Entpacken mit Rust-Bibliotheken aus dem Archiv ein anderes, als erwartetes, Inhalt extrahiert wird.
Beispielsweise kann ein Angreifer ein modifiziertes Archiv in das PyPI-Repository hochladen, das die Überprüfung basierend auf der Analyse des Inhalts des Hauptarchivs besteht, das die legitime Datei pyproject.toml enthält. Bei der Verarbeitung dieses Pakets mit dem Tool uv wird die legitime pyproject.toml durch eine bösartige Version aus dem verschachtelten Archiv ersetzt, die Anweisungen enthält, die beim Build auf dem Computer des Entwicklers oder in einem kontinuierlichen Integrationssystem ausgeführt werden. Analog dazu können Dateien des Containers beim Entpacken des Container-Images mit dem Testcontainers-Toolkit überschrieben werden.
Quelle: opennet.ru
