Nella libreria async-tar, scritta in Rust e che offre funzioni per la lettura e la scrittura di archivi tar, è stata scoperta una vulnerabilità (CVE-2025-62518, nome in codice TARmageddon) che consente, durante l'estrazione di un archivio tar appositamente formattato, non solo di estrarre i file contenuti, ma anche i file presenti in un archivio tar annidato. La vulnerabilità può essere utilizzata per eludere i sistemi di verifica degli archivi e per estrarre file per cui non è stata effettuata alcuna verifica.
La vulnerabilità si manifesta anche nei fork della libreria async-tar, come tokio-tar, krata-tokio-tar e astral-tokio-tar, così come nelle utility basate su di esse, ad esempio nel gestore di pacchetti uv, sviluppato come sostituzione ad alte prestazioni di "pip" per progetti in Python. Tra i progetti popolari che utilizzano librerie vulnerabili ci sono anche l'ecosistema testcontainers per l'esecuzione di container 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 errata della posizione durante l'analisi dei diversi valori di dimensione nelle intestazioni ustar e PAX. Negli archivi tar nel formato PAX, per ogni file all'interno dell'archivio sono indicate due intestazioni — la classica ustar e la estesa PAX. Il problema è dato dal fatto che le librerie vulnerabili, durante l'estrazione dei file, invece di calcolare lo spostamento basato sulla dimensione dall'intestazione estesa PAX, utilizzavano la dimensione dell'intestazione ustar obsoleta. Con una dimensione nulla 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 è indicata una dimensione nulla, mentre nell'intestazione per il formato PAX è indicata la dimensione reale, causando così il trattamento 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 risolta 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 dei patch separati.
Le vulnerabilità nelle librerie hanno ricevuto un livello di pericolosità di 8,1 su 10, poiché il problema può essere utilizzato per sovrascrivere i file estratti (nelle implementazioni vulnerabili verranno estratti file diversi da quelli visibili nell'archivio). Tuttavia, la vulnerabilità nel gestore pacchetti uv è segnalata come non pericolosa, poiché se un attaccante può influenzare il contenuto dell'archivio sorgente, non ha senso complicare l'attacco sfruttando la vulnerabilità tramite un archivio nidificato, quando può ottenere l'esecuzione del codice attraverso gli script di build nell'archivio principale.
I ricercatori che hanno identificato la vulnerabilità hanno suggerito diversi scenari ipotetici di attacco che consentono di bypassare le verifiche di sicurezza e ottenere l'esecuzione del codice sostituendo i file di configurazione o interferendo nel processo di build. Si presuppone che l'archivio inviato possa superare la verifica automatizzata di un scanner di sicurezza e l'audit manuale, durante il quale chi controlla non noterà un archivio nidificato strano con altri file; dopodiché, durante l'estrazione utilizzando le librerie Rust, verrà estratto un contenuto diverso da quello atteso.
Ad esempio, un attaccante può caricare un archivio modificato nel repository PyPI, che supererà la verifica basata sull'analisi del contenuto dell'archivio principale, contenente un file legittimo pyproject.toml. Quando questo pacchetto viene elaborato con l'utilità uv, il legittimo pyproject.toml verrà sostituito con una versione malevola dall'archivio nidificato, contenente comandi che verranno eseguiti durante la build sul computer dello sviluppatore o nel sistema di integrazione continua. Allo stesso modo, è possibile organizzare la sovrascrittura dei file del container durante l'estrazione dell'immagine del container utilizzando l'utility testcontainers.
Fonte: opennet.ru
