{"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\/en\/blog\/news\/uyazvimost-v-rust-bibliotekah-dlya-formata-tar-privodyashhaya-k-raspakovke-fajlov-iz-vlozhennogo-arhiva","title":{"rendered":"Vulnerability in Rust libraries for TAR format that leads to extracting files from a nested archive","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
A vulnerability (CVE-2025-62518, codename TARmageddon) has been identified in the Rust library async-tar, which provides functions for reading and writing tar archives. This vulnerability allows specially crafted tar archives to extract not only files contained within them but also files present in nested tar archives upon extraction. This vulnerability can be exploited to bypass archive verification systems and extract files that were not subject to checks. <\/p>\n
The vulnerability also appears in forks of the async-tar library, such as tokio-tar, krata-tokio-tar, and astral-tokio-tar, as well as in utilities based on them, such as the uv package manager, developed as a high-performance alternative to 'pip' for Python projects. Notable projects that use vulnerable libraries include the testcontainers toolkit for running docker containers and the WebAssembly runtime wasmCloud. In the crates.io repository, the async-tar library has seen 1.3 million downloads in the last 90 days, tokio-tar has 2.2 million, and testcontainers has 2.9 million. <\/p>\n
The vulnerability is caused by an incorrect choice of position when parsing different size values in ustar and PAX headers. In tar archives in PAX format, two headers are specified for each file inside the archive\u2014the classic ustar and the extended PAX. The issue arises because the vulnerable libraries, when unpacking files, used the size from the outdated ustar header instead of calculating the offset based on the size from the extended PAX header. With a zero size value in the ustar header, the content following it was processed as a valid TAR header block for the next file.
<\/center>
<\/center> <\/p>\n
To exploit the vulnerability, it is sufficient to create a TAR archive where the ustar header specifies a zero size, and the PAX header contains the actual size, causing the contents of the file with another tar archive to be processed as part of the main archive. Example code for creating such archives is available on GitHub. The vulnerability has been patched in releases of tokio-tar 0.5.6 and uv 0.9.5. Fixes for other libraries have not yet been published, but patches have been prepared separately for astral-tokio-tar, async-tar, and krata-tokio-tar. <\/p>\n
Vulnerabilities in the libraries have been assigned a danger level of 8.1 out of 10, as the issue can be exploited to overwrite unpacked files (vulnerable implementations will unpack files different from those visible in the archive). Meanwhile, the vulnerability in the uv package manager is marked as non-threatening, as if an attacker can influence the contents of the original archive, there is no point in complicating the attack and exploiting the vulnerability through a nested archive when code execution can be achieved through build scripts in the main archive. <\/p>\n
The researchers who discovered the vulnerability proposed several hypothetical attack scenarios that allow bypassing security checks and achieving code execution through configuration file replacements or interference in the build process. It is implied that the submitted archive will pass automated checks by the security scanner and manual audits, during which the auditor may not notice the suspicious nested archive containing other files. Consequently, when unpacked using Rust libraries, different content than expected will be extracted from the archive. <\/p>\n
For instance, an attacker could upload a modified archive to the PyPI repository, which would pass verification based on the analysis of the main archive's contents, containing a legitimate pyproject.toml file. When processing this package using the uv utility, the legitimate pyproject.toml will be replaced with a malicious version from the nested archive containing commands that will execute during the building process on the developer's computer or in the continuous integration system. Similarly, files in the container can be overwritten when extracting the container image using the testcontainers toolkit. \n Source: opennet.ru<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"
![\"Vulnerability](\"\/wp-content\/uploads\/2025\/10\/7de5eeee8420b77faa0bca075f275700.png\")
<\/center> ![\"Vulnerability](\"\/wp-content\/uploads\/2025\/10\/538645342d5a4408b327ffd87c659c4f.png\")
<\/center> <\/p>\n