TARmageddon (CVE-2025-62518) — błąd w popularnych bibliotekach Rust TAR umożliwia RCE i ataki na łańcuch dostaw

Wprowadzenie do problemu / definicja luki

TARmageddon (CVE-2025-62518) to wysoka podatność (CVSS 8.1) w ekosystemie Rust dotycząca parserów archiwów TAR w bibliotekach asynchronicznych: pierwotnie async-tar, a następnie najpopularniejszego forka tokio-tar oraz jego odgałęzień (m.in. astral-tokio-tar). Błąd pozwala na „przemycanie” dodatkowych wpisów archiwum i w konsekwencji na zdalne wykonanie kodu (RCE) poprzez nadpisywanie plików — np. konfiguracji — podczas rozpakowywania. Odkrycia i koordynację ujawnienia przeprowadził zespół Edera.

W skrócie

• Co: desynchronizacja parsera TAR przy specyficznym zestawie nagłówków PAX/ustar → interpretacja danych wewnętrznego archiwum jako legalnych wpisów zewnętrznego.
• Wpływ: możliwość nadpisania plików i RCE; ryzyko w łańcuchu dostaw (narzędzia build/test, menedżery pakietów); niepełne skanowanie BOM.
• Kogo dotyczy: projekty używające tokio-tar i forków, w tym astral-tokio-tar (naprawione w 0.5.6), częściowo narzędzia jak uv (Python) i biblioteki testowe; skala trudna do oszacowania z powodu porzuconych upstreamów.
• Status: aktywnie utrzymywane forki (Astral) są załatane; oryginalny tokio-tar pozostaje nieutrzymywany. Zalecana migracja/aktualizacja.

Kontekst / historia / powiązania

Genealogia bibliotek wygląda następująco: async-tar → (fork) tokio-tar → (forki) krata-tokio-tar i astral-tokio-tar. Najpopularniejszy fork tokio-tar (miliony pobrań na crates.io) jest de facto abandonware, co utrudniło typowy proces „jednego patcha upstream”. Edera przeprowadziła zdecentralizowane ujawnienie, współpracując bezpośrednio z maintainerami aktywnych forków i wybranymi projektami downstream (m.in. testcontainers, Binstalk, liboxen, wasmCloud).

W praktyce najważniejszy dziś dla użytkowników jest fork astral-tokio-tar, na którym bazuje m.in. superszybki menedżer pakietów Python uv; astral-tokio-tar otrzymał łatkę w wersji 0.5.6 oraz oficjalne advisory.

Analiza techniczna / szczegóły luki

Podatność to błąd logiki w wyznaczaniu granic danych wpisu TAR, ujawniający się przy zagnieżdżonych archiwach i rozbieżnościach między nagłówkiem PAX a ustar:

1. Wpis ma nagłówki PAX i ustar.
2. PAX poprawnie podaje rozmiar pliku (np. X bajtów).
3. ustar błędnie podaje 0 bajtów.
4. Parser (w podatnych wersjach) przesuwa pozycję strumienia wg ustar (0), ignorując PAX.
5. Trafia więc natychmiast na początek wewnętrznego archiwum i błędnie interpretuje jego nagłówki jako kolejne wpisy zewnętrznego TAR.

Efekt: „przemycone” wpisy zostają rozpakowane, mogą nadpisać istniejące pliki i uruchomić nieoczekiwane ścieżki wykonania. To nie jest problem pamięciowy (Rust chroni przed UAF/BOF), lecz klasyczny błąd parsowania/protokołu.

Praktyczne konsekwencje / ryzyko

• RCE przez nadpisanie konfiguracji: np. podmiana plików konfiguracyjnych podczas instalacji/rozpakowywania.
• Ataki na łańcuch dostaw:
  • Hijacking build backend w ekosystemie Pythona: różny wynik ekstrakcji między instalatorami (uv vs inne) umożliwia wstrzyknięcie lub podmianę plików sterujących budową.
  • Zatrucie warstw obrazów/kontenerów lub środowisk testowych (np. testcontainers) — dołączenie nieprzeskanowanych plików.
• Omijanie skanerów/BOM: skaner zatwierdza „czyste” zewnętrzne TAR, podczas gdy rozpakowanie przy użyciu podatnej biblioteki wprowadza dodatkowe, niezatwierdzone pliki.

Rekomendacje operacyjne / co zrobić teraz

Deweloperzy i właściciele projektów:

1. Zidentyfikuj zależności: sprawdź, czy używasz tokio-tar/astral-tokio-tar/async-tar bezpośrednio lub pośrednio.
2. Aktualizuj do wersji załatanej:
   • astral-tokio-tar → ≥ 0.5.6 (advisory GHSA-j5gw-2vrg-8fgx).
   • Jeżeli używasz narzędzi opartych o astral-tokio-tar (np. uv), zastosuj wersje usuwające różnice w ekstrakcji i zalecenia z advisory projektu.
3. Rozważ migrację: jeśli nie możesz szybko załatać, rozważ przejście na standardowy tar crate (sync); w kodzie async owiń operacje w tokio::task::spawn_blocking.
4. Wprowadź walidacje parsera (jeśli utrzymujesz własny fork):
   • priorytet nagłówków PAX przy ustalaniu rozmiaru,
   • kontrola spójności PAX/ustar,
   • twarde sprawdzanie granic danych.

Środki ograniczające ryzyko (krótkoterminowo):

• Zliczanie i porównywanie liczby/rozmiarów rozpakowanych plików z oczekiwanym manifestem;
• Skany post-ekstrakcyjne katalogu docelowego;
• Rozpakowywanie w piaskownicy z limitami rozmiaru/ilości;
• Wyłączanie nadpisywania istniejących plików podczas ekstrakcji, o ile to możliwe.

Różnice / porównania z innymi przypadkami (jeśli dotyczy)

• Nie jest to path traversal znany z innych problemów TAR; tutaj chodzi o różnicę w interpretacji nagłówków, która skutkuje „dopisaniem” ukrytych plików do listy wpisów. (Osobne advisories dot. path traversal istnieją w astral-tokio-tar, ale to inny kod/inny wektor).
• Nie jest to błąd pamięciowy — Rust eliminuje całą klasę takich podatności, lecz błędy logiki w parserach/protokole nadal są możliwe i groźne.

Podsumowanie / kluczowe wnioski

TARmageddon pokazuje, że bezpieczeństwo języka nie zastąpi bezpieczeństwa projektowego. Gdy popularny komponent staje się „porzucony”, ryzyko rozlewa się po całym ekosystemie. Dla zespołów:

• Inwentaryzacja łańcucha zależności i szybkie aktualizacje to must-have.
• Defense-in-depth dla operacji ekstrakcji: sandbox, weryfikacja manifestów, zakaz nadpisywania.
• Polityka dla forków: preferuj aktywnie utrzymywane odgałęzienia z jasnym procesem security.

Źródła / bibliografia

1. Edera — ogłoszenie podatności TARmageddon (CVE-2025-62518), szczegóły techniczne i timeline, 21 października 2025. (edera.dev)
2. GitHub Advisory dla astral-tokio-tar (GHSA-j5gw-2vrg-8fgx) — poprawka w 0.5.6. (GitHub)
3. NVD — wpis CVE-2025-62518 (opis i komponenty). (NVD)
4. Advisory projektu uv (różnice w ekstrakcji z PAX) — wpływ downstream. (GitHub)
5. SecurityWeek — przegląd wpływu na ekosystem i status utrzymania forków. (SecurityWeek)