Nella libreria async-tar, scritta in Rust e che fornisce funzionalità per la lettura e la scrittura di archivi tar, è stata individuata una vulnerabilità (CVE-2025-62518, nome in codice TARmageddon) che consente, durante l'estrazione di un archivio tar appositamente creato, non solo di estrarre i file contenuti, ma anche i file presenti in archivi tar annidati. Questa vulnerabilità può essere sfruttata per eludere i sistemi di verifica degli archivi e per estrarre file senza che venga eseguita una verifica.
La vulnerabilità si manifesta anche nelle fork della libreria async-tar, come tokio-tar, krata-tokio-tar e astral-tokio-tar, oltre che negli strumenti basati su di esse, ad esempio nel gestore di pacchetti uv, sviluppato come sostituto ad alta prestazione di 'pip' per progetti in Python. Tra i progetti popolari che utilizzano queste librerie vulnerabili si segnalano anche l'insieme di strumenti testcontainers per l'esecuzione di contenitori docker e il runtime WebAssembly wasmCloud. Nel repository crates.is, negli ultimi 90 giorni, la libreria async-tar ha registrato 1,3 milioni di download, tokio-tar 2,2 milioni, e testcontainers 2,9 milioni.
La vulnerabilità è causata da una scelta di posizione errata durante l'analisi dei diversi valori di dimensione negli header ustar e PAX. Nei file tar nel formato PAX, per ogni file all'interno dell'archivio sono presenti due intestazioni: la classica ustar e l'ampliata PAX. Il problema è che le librerie vulnerabili, durante l'estrazione dei file, anziché calcolare l'offset basandosi sulla dimensione dall'intestazione ampliata PAX, prendevano la dimensione dall'intestazione ustar obsoleta. Con un valore di dimensione nullo nell'intestazione ustar, il contenuto successivo del file veniva elaborato come un blocco di intestazioni TAR valido per il file successivo.
Per effettuare un attacco, è sufficiente creare un archivio TAR in cui nell'intestazione ustar sia indicata una dimensione nulla, mentre nell'intestazione per il formato PAX sia indicata la dimensione reale, il che provoca l'elaborazione del contenuto di un file con un altro archivio tar come parte dell'archivio principale. Un esempio di codice per creare tali archivi è disponibile su GitHub. La vulnerabilità è stata corretta nelle versioni tokio-tar 0.5.6 e uv 0.9.5. Per le altre librerie, le correzioni non sono state ancora pubblicate, ma per astral-tokio-tar, async-tar e krata-tokio-tar sono stati preparati patch separati.
Le vulnerabilità nelle librerie hanno ricevuto un livello di pericolo di 8,1 su 10, poiché il problema può essere sfruttato per sovrascrivere file estratti (in implementazioni vulnerabili verranno estratti file diversi da quelli visibili nell'archivio). Tuttavia, la vulnerabilità nel gestore di pacchetti uv è stata segnalata come non pericolosa, poiché se un attaccante può influenzare il contenuto dell'archivio sorgente, non ha senso complicare l'attacco e sfruttare la vulnerabilità attraverso un archivio annidato, quando può ottenere l'esecuzione di codice tramite script di build nell'archivio principale.
I ricercatori che hanno scoperto la vulnerabilità hanno proposto diversi scenari ipotetici di attacco che consentono di eludere i controlli di sicurezza e ottenere l'esecuzione di codice attraverso la sostituzione dei file di configurazione o l'interferenza nel processo di build. Si presume che l'archivio inviato possa superare un controllo automatizzato da parte di uno scanner di sicurezza e un audit manuale, durante il quale il verificatore non noterà un archivio annidato sospetto con altri file, dopo di che, durante l'estrazione utilizzando le librerie Rust, verrà estratto un contenuto diverso da quello atteso.
Ad esempio, un attaccante potrebbe caricare un archivio modificato nel repository PyPI, che passerà il controllo basato sull'analisi del contenuto dell'archivio principale, contenente un file pyproject.toml legittimo. Durante l'elaborazione di questo pacchetto utilizzando lo strumento uv, il legittimo pyproject.toml sarà sostituito da una versione dannosa dell'archivio interno, contenente comandi che verranno eseguiti durante la compilazione sul computer dello sviluppatore o nel sistema di integrazione continua. Allo stesso modo, è possibile organizzare la riscrittura dei file del contenitore durante l'estrazione dell'immagine del contenitore utilizzando lo strumento testcontainers.
Fonte: opennet.ru
