airineiandrei/tarmageddon-cve-2025-62518-PoC pour CVE-2025-62518 démontrant la contrebande d'archives tar via l'analyse des en-têtes PAX de tokio-tar, créant des charges utiles malveillantes et un extracteur vulnérable pour montrer l'injection dans la chaîne d'approvisionnement.
Vidéo : https://youtu.be/EYBB4BHsp9E
./outputmalicious.tar simple avec un exemple de contenu dissimulé, les commentaires expliquent étape par étape et bloc par bloc ce qui est faitUtilisez le script de reproduction fourni ou faites-le manuellement
Exécutez malicious-payload pour générer la charge utile
malicious.tarEn passant ce fichier à notre application vulnerable-extract, on obtient :
/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
Alors que l'utilitaire tar fourni par notre OS ((GNU tar) 1.35 dans ce cas) donne :
malicious-payload$ tar -tvf malicious.tar
---------- 0/0 1024 1970-01-01 02:00 benign_file.txt
Notez qu'il voit la taille du fichier comme étant 1024
Alternativement, utiliser astral-tokio-tar 0.5.6 au lieu de l'abandonné tokio-tar 0.3.1 extrait correctement l'archive.
CVE-2025-62518 (TARmageddon) est une vulnérabilité de sécurité découverte dans la bibliothèque Rust tokio-tar (vulnérabilité Rust 😮). Il s'agit d'une erreur logique dans la manière dont les en-têtes du format tar sont analysés, permettant à un attaquant de dissimuler des fichiers.
Le défaut réside dans la logique de gestion des en-têtes étendus PAX. Dans une archive TAR, il existe différents types d'en-têtes :
USTAR : L'en-tête standard contenant le nom du fichier, les permissions et la taille.PAX (Type x) : Un en-tête d'extension utilisé pour fournir des métadonnées (comme une très grande taille de fichier) pour le fichier suivant dans l'archive.Lorsqu'un en-tête PAX est présent, un analyseur doit résoudre la taille réelle du fichier en priorisant les métadonnées PAX par rapport à l'en-tête standard USTAR.
Mais POURQUOI y a-t-il 2 types d'en-têtes qui ont des priorités pour ce qui semble être la même chose ? Parce que le format TAR est ancien (normalisé en 1988), et USTAR a ses limites (taille jusqu'à 8 Go, nom de fichier jusqu'à 256 caractères). C'est un problème, donc l'en-tête PAX a été ajouté en 2001 pour permettre des fichiers plus grands et des noms de fichiers plus longs.
Dans les versions vulnérables de tokio-tar, l'analyseur adopte correctement la taille de l'en-tête PAX pour le lecteur de contenu du fichier, mais il utilise incorrectement la taille de l'en-tête USTAR pour déterminer où commence l'en-tête du fichier suivant.
Le cœur du problème est un décalage de pointeur. Lorsque la bibliothèque vulnérable traite un fichier, elle utilise deux « têtes » internes différentes pour lire le flux :
Dans une archive normale, ces deux têtes sont d'accord. Dans TARmageddon, nous les forçons à être en désaccord. En définissant la taille PAX à 1024 et la taille USTAR à 0, nous créons un paradoxe :
benign_file.txt.0 dans l'en-tête USTAR et pense : « Je suis déjà à la fin du fichier. » Elle reste exactement là où elle est.Par conséquent, la tête d'analyse traite les données à l'intérieur du bloc de 1024 octets comme le prochain ensemble d'instructions. Si ces données ressemblent à un en-tête TAR valide, la bibliothèque va « découvrir » et extraire un second fichier qui n'existe techniquement pas selon la structure globale de l'archive.
La charge utile dissimulée :
La charge utile est conçue comme une séquence de blocs de 512 octets. Voici la disposition utilisée dans le générateur malicious-payload :
| Bloc | Rôle | Description |
|---|---|---|
| 1 & 2 | Métadonnées PAX | Affirme que le fichier suivant a une longueur de 1024 octets. |
| 3 | En-tête de base | benign.txt. Crucialement, définit la taille à 0. |
| 4 | En-tête dissimulé | backdoor.sh. Caché dans la zone « données ». |
| 5 | Données dissimulées | Le contenu malveillant (p. ex., alias shell). |
| 6 & 7 | Fin de fichier (EOF) | Terminaison standard par blocs nuls. |
Parce que les outils standards (comme GNU tar) suivent correctement la taille PAX, ils voient les blocs 4 et 5 comme des données binaires inoffensives appartenant à benign_file.txt. Ils n'« exécutent » jamais l'en-tête du bloc 4.
Comment cette caisse (crate) ayant une vulnérabilité peut-elle être exploitée ? Pourquoi le fait qu'un fichier soit dissimulé dans une archive est-il important ?
Un attaquant dissimule des fichiers malveillants dans un système de build. L'extraction de ceux-ci, que ce soit pour le développement ou sur une machine CI, peut écraser des fichiers de build légitimes, compromettre cette machine et même tromper le système de build pour qu'il signe des fichiers malveillants.
Un scanner inspecte un fichier .tar, ne le scannant que dans le mode correct ; des fichiers indésirables peuvent être présents lors de l'extraction mais n'ont pas été scannés.
Inspiré par cette analyse