{"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\/novosti-interneta\/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 porta allo svolgimento di file da archivi nidificati.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Nella libreria async-tar, scritta in Rust e che fornisce funzionalit\u00e0 per la lettura e la scrittura di archivi tar, \u00e8 stata individuata una vulnerabilit\u00e0 (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\u00e0 pu\u00f2 essere sfruttata per eludere i sistemi di verifica degli archivi e per estrarre file senza che venga eseguita una 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, cos\u00ec come negli strumenti basati su di esse, ad esempio nel gestore di pacchetti uv, sviluppato come un'alternativa ad alte prestazioni a \u00abpip\u00bb per progetti in Python. Tra i progetti popolari che utilizzano le librerie vulnerabili ci sono anche lo strumento testcontainers per eseguire 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. <\/p>\n
La vulnerabilit\u00e0 \u00e8 causata da una scelta errata della posizione durante l'analisi dei diversi valori di dimensione nelle intestazioni ustar e PAX. Negli archivi tar in formato PAX, per ogni file all'interno dell'archivio sono specificate due intestazioni: la classica ustar e l'estesa PAX. Il problema \u00e8 dovuto al fatto che le librerie vulnerabili, durante l'estrazione dei file, anzich\u00e9 calcolare l'offset basato sulla dimensione dall'intestazione estesa PAX, prendevano la dimensione dall'intestazione obsoleta ustar. 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.
<\/center>
<\/center> <\/p>\n
Per effettuare un attacco, \u00e8 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 \u00e8 disponibile su GitHub. La vulnerabilit\u00e0 \u00e8 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. <\/p>\n
Le vulnerabilit\u00e0 nelle librerie hanno ricevuto un livello di pericolo di 8,1 su 10, poich\u00e9 il problema pu\u00f2 essere sfruttato per sovrascrivere file estratti (in implementazioni vulnerabili verranno estratti file diversi da quelli visibili nell'archivio). Tuttavia, la vulnerabilit\u00e0 nel gestore di pacchetti uv \u00e8 stata segnalata come non pericolosa, poich\u00e9 se un attaccante pu\u00f2 influenzare il contenuto dell'archivio sorgente, non ha senso complicare l'attacco e sfruttare la vulnerabilit\u00e0 attraverso un archivio annidato, quando pu\u00f2 ottenere l'esecuzione di codice tramite script di build nell'archivio principale. <\/p>\n
I ricercatori che hanno scoperto la vulnerabilit\u00e0 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\u00e0 un archivio annidato sospetto con altri file, dopo di che, durante l'estrazione utilizzando le librerie Rust, verr\u00e0 estratto un contenuto diverso da quello atteso. <\/p>\n
Ad esempio, un attaccante potrebbe caricare un archivio modificato nel repository PyPI, che passer\u00e0 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\u00e0 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, \u00e8 possibile organizzare la riscrittura dei file del contenitore durante l'estrazione dell'immagine del contenitore utilizzando lo strumento 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