Tarmageddon CVE-2025-62518

Video: https://youtu.be/EYBB4BHsp9E

Directory del repository

• vulnerable-extract esempio minimale riproducibile, prende un percorso come argomento ed estrae quel file in ./output
• malicious-payload crea un semplice archivio malicious.tar con alcuni esempi di contenuti nascosti, i commenti spiegano cosa viene fatto passo dopo passo e blocco per blocco

Riproduzione

Usa lo script di riproduzione fornito reproduce script o fallo manualmente

Esegui malicious-payload per generare il payload malicious.tar

Passando questo file alla nostra app vulnerable-extract si ottiene:

/vulnerable-extract$ ll output/
total 12
drwxrwxr-x 2 airinei airinei 4096 Jan 19 22:40 ./
drwxrwxr-x 5 airinei airinei 4096 Jan 19 22:40 ../
-rw-rw-r-- 1 airinei airinei    0 Jan  1  1970 benign_file.txt
-rw-rw-r-- 1 airinei airinei   18 Jan  1  1970 sh_profile_hijack

Mentre eseguendo l'utility tar fornita dal nostro sistema operativo ((GNU tar) 1.35 in questo caso) si ottiene:

malicious-payload$ tar -tvf malicious.tar
---------- 0/0            1024 1970-01-01 02:00 benign_file.txt

Nota che vede la dimensione del file è 1024

In alternativa usando astral-tokio-tar 0.5.6 invece del deprecato tokio-tar 0.3.1 estrae correttamente l'archivio.

Spiegazione

CVE-2025-62518 (TARmageddon) è una vulnerabilità di sicurezza trovata nella libreria Rust tokio-tar (vulnerabilità Rust 😮). Si tratta di un errore logico nel modo in cui vengono analizzati gli header del formato tar, che permette a un attaccante di introdurre file di contrabbando.

Il difetto risiede nella logica di gestione degli header estesi PAX. In un archivio TAR, esistono diversi tipi di header:

• USTAR: L'header standard che contiene nome file, permessi e dimensione.
• PAX (Type x): Un header di estensione usato per fornire metadati (come una dimensione del file molto grande) per il file successivo nell'archivio.

Quando è presente un header PAX, un parser deve risolvere la dimensione effettiva del file dando priorità ai metadati PAX rispetto all'header standard USTAR.

Ma PERCHÉ ci sono 2 tipi di header che hanno priorità per ciò che apparentemente è la stessa cosa? Perché il formato TAR è vecchio (standardizzato nel 1988), e USTAR ha le sue limitazioni (dimensione fino a 8GB, nome file fino a 256 caratteri). Questo è un problema quindi l'header PAX è stato aggiunto nel 2001 per permettere file più grandi e nomi più lunghi.

Nelle versioni vulnerabili di tokio-tar, il parser adotta correttamente la dimensione dall'header PAX per il lettore del contenuto del file, ma usa erroneamente la dimensione dall'header USTAR per determinare dove inizia l'header del file successivo.

Il cuore del problema è una discrepanza di puntatori. Quando la libreria vulnerabile elabora un file, usa due diverse "teste" interne per leggere il flusso:

1. La Testa del Contenuto: Responsabile di leggere i byte effettivi del file e scriverli su disco.
2. La Testa del Parser: Responsabile di saltare i dati del file per trovare l'header del prossimo file.

In un archivio normale, queste due teste concordano. In TARmageddon, le forziamo a discordare. Impostando la dimensione PAX a 1024 e la dimensione USTAR a 0, creiamo un paradosso:

• La Testa del Contenuto legge 1024 byte e li mette in benign_file.txt.
• La Testa del Parser vede lo 0 nell'header USTAR e pensa, "Sono già alla fine del file." Rimane esattamente dove si trova.

Di conseguenza, la Testa del Parser tratta i dati all'interno del blocco di 1024 byte come il successivo insieme di istruzioni. Se quei dati assomigliano a un header TAR valido, la libreria "scoprirà" ed estrarrà un secondo file che tecnicamente non esiste secondo la struttura globale dell'archivio.

Il Payload di Contrabbando:

Il payload è costruito come una sequenza di blocchi da 512 byte. Ecco la disposizione usata nel generatore malicious-payload:

Poiché gli strumenti standard (come GNU tar) seguono correttamente la dimensione PAX, vedono Blocco 4 e 5 come dati binari innocui appartenenti a benign_file.txt. Non "eseguono" mai l'header nel Blocco 4.

Come è una vulnerabilità, e un CVSS 8.1?

Come può essere sfruttata questa vulnerabilità della crate, perché è importante che un file venga introdotto di nascosto in un archivio?

Iniezione nella Catena di Fornitura:

Un attaccante introduce file malevoli in un sistema di build. Estrarre l'archivio per sviluppo o su una macchina CI può sovrascrivere file di build legittimi, compromettendo quella macchina e persino ingannando il sistema di build per firmare file malevoli.

Bypass della Sicurezza (WAF/AV):

Uno scanner ispeziona un .tar, analizzandolo solo nella modalità corretta, file indesiderati potrebbero essere presenti all'estrazione ma non sono stati scansionati

Ispirato da questo writeup