{"id":146043,"date":"2025-10-21T23:12:42","date_gmt":"2025-10-21T21:12:43","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/uyazvimost-v-rust-bibliotekah-dlya-formata-tar-privodyashhaya-k-raspakovke-fajlov-iz-vlozhennogo-arhiva"},"modified":"2025-10-21T23:12:42","modified_gmt":"2025-10-21T21:12:43","slug":"uyazvimost-v-rust-bibliotekah-dlya-formata-tar-privodyashhaya-k-raspakovke-fajlov-iz-vlozhennogo-arhiva","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/news\/uyazvimost-v-rust-bibliotekah-dlya-formata-tar-privodyashhaya-k-raspakovke-fajlov-iz-vlozhennogo-arhiva","title":{"rendered":"Vulnerabilit\u00e0 nelle librerie Rust per il formato TAR che consente l'estrazione di file da archivi annidati","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Nella libreria async-tar, scritta in Rust e che offre funzioni per la lettura e la scrittura di archivi tar, \u00e8 stata scoperta una vulnerabilit\u00e0 (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\u00e0 pu\u00f2 essere utilizzata per eludere i sistemi di verifica degli archivi e per estrarre file per cui non \u00e8 stata effettuata alcuna verifica. <\/p>\n
La vulnerabilit\u00e0 si manifesta anche nei fork della libreria async-tar, come tokio-tar, krata-tokio-tar e astral-tokio-tar, oltre che negli strumenti basati su di essa, come il gestore di pacchetti uv, sviluppato come sostituto ad alte prestazioni di 'pip' per progetti in linguaggio Python. Tra i progetti pi\u00f9 noti che utilizzano le librerie vulnerabili ci sono anche il toolkit testcontainers per l'avvio 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. <\/p>\n
La vulnerabilit\u00e0 \u00e8 causata da una selezione errata della posizione durante l'analisi dei diversi valori di dimensione negli header ustar e PAX. Negli archivi tar nel formato PAX, per ogni file all'interno dell'archivio vengono forniti due header: il classico ustar e l'esteso PAX. Il problema \u00e8 che le librerie vulnerabili, durante l'estrazione dei file, anzich\u00e9 calcolare l'offset basandosi sulla dimensione dell'header esteso PAX, prendevano la dimensione dall'header obsoleto ustar. Con un valore di dimensione nullo nell'header ustar, il contenuto successivo del file veniva trattato come un blocco header TAR valido per il file successivo.
<\/center>
<\/center> <\/p>\n
Per effettuare un attacco \u00e8 sufficiente creare un archivio TAR in cui nell'intestazione ustar \u00e8 indicata una dimensione nulla, mentre nell'intestazione per il formato PAX \u00e8 indicata la dimensione reale, causando cos\u00ec 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 \u00e8 disponibile su GitHub. La vulnerabilit\u00e0 \u00e8 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. <\/p>\n
Le vulnerabilit\u00e0 nelle librerie hanno ricevuto un livello di pericolosit\u00e0 di 8,1 su 10, poich\u00e9 il problema pu\u00f2 essere utilizzato per sovrascrivere i file estratti (nelle implementazioni vulnerabili verranno estratti file diversi da quelli visibili nell'archivio). Tuttavia, la vulnerabilit\u00e0 nel gestore pacchetti uv \u00e8 segnalata come non pericolosa, poich\u00e9 se un attaccante pu\u00f2 influenzare il contenuto dell'archivio sorgente, non ha senso complicare l'attacco sfruttando la vulnerabilit\u00e0 tramite un archivio nidificato, quando pu\u00f2 ottenere l'esecuzione del codice attraverso gli script di build nell'archivio principale. <\/p>\n
I ricercatori che hanno identificato la vulnerabilit\u00e0 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\u00e0 un archivio nidificato strano con altri file; dopodich\u00e9, durante l'estrazione utilizzando le librerie Rust, verr\u00e0 estratto un contenuto diverso da quello atteso. <\/p>\n
Ad esempio, un attaccante pu\u00f2 caricare un archivio modificato nel repository PyPI, che superer\u00e0 la verifica basata sull'analisi del contenuto dell'archivio principale, contenente un file legittimo pyproject.toml. Quando questo pacchetto viene elaborato con l'utilit\u00e0 uv, il legittimo pyproject.toml verr\u00e0 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, \u00e8 possibile organizzare la sovrascrittura dei file del container durante l'estrazione dell'immagine del container utilizzando l'utility testcontainers. \n Fonte: opennet.ru<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"
![\"Vulnerabilit\u00e0](\"\/wp-content\/uploads\/2025\/10\/7de5eeee8420b77faa0bca075f275700.png\")
<\/center> ![\"Vulnerabilit\u00e0](\"\/wp-content\/uploads\/2025\/10\/538645342d5a4408b327ffd87c659c4f.png\")
<\/center> <\/p>\n