## https://sploitus.com/exploit?id=F387DF35-F974-5FAE-B3A7-6AC2DDF2DFD3
# Tarmageddon [CVE-2025-62518](https://nvd.nist.gov/vuln/detail/CVE-2025-62518)
## Repo directories
- [vulnerable-extract](vulnerable-extract) minimal repoducible example, takes a path as arg, and extracts that file to `./output`
- [malicious-payload](malicious-payload) creates a simple `malicious.tar` archive with some example of smuggled content, comments explain what is being done step by step and block by block
## Reproduction
Use the provided [reproduce script](reproduce.sh) or do it manually
Run `malicious-payload` to generate the payload `malicious.tar`
Passing this file to our `vulnerable-extract` app yields:
```
/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
```
While running our OS provided `tar` (`(GNU tar) 1.35` in this case) utilitary yields:
```
malicious-payload$ tar -tvf malicious.tar
---------- 0/0 1024 1970-01-01 02:00 benign_file.txt
```
Note that it sees the size of the file is `1024`
Alternatively using `astral-tokio-tar 0.5.6` instead of the abandoned `tokio-tar 0.3.1` correctly extract the archive.
## Writeup
*CVE-2025-62518* (TARmageddon) is a security vulnerability found in the `tokio-tar` Rust library (Rust vulnerability :open_mouth:). This is a logic error in how the headers of the tar format are parsed, allowing an attacker to smuggle files.
The flaw exists in the logic handling PAX Extended Headers. In a TAR archive, there are different header types:
- `USTAR`: The standard header containing filename, permissions, and size.
- `PAX (Type x)`: An extension header used to provide metadata (like a very large file size) for the next file in the archive.
When a `PAX` header is present, a parser must resolve the file's actual size by prioritizing the `PAX` metadata over the standard `USTAR` header.
But **WHY** are there `2` types of headers that have priorities for what looks like the same thing? Because the `TAR` format is old (standardized in `1988`), and `USTAR` has it limitations (size up to `8GB`, filename up to `256` characters). That's a problem so `PAX` header was added in `2001` to allow bigger files and longer filenames.
In vulnerable versions of `tokio-tar`, the parser correctly adopts the size from the `PAX` header for the file content reader, but it incorrectly uses the size from the `USTAR` header to determine where the next file header begins.
The core of the issue is a **pointer mismatch**. When the vulnerable library processes a file, it uses two different internal "heads" to read the stream:
1. **The Content Head:** Responsible for reading the actual bytes of the file and writing them to disk.
2. **The Parser Head:** Responsible for skipping over file data to find the *next* file header.
In a normal archive, these two heads agree. In **TARmageddon**, we force them to disagree. By setting the `PAX` size to **1024** and the `USTAR` size to **0**, we create a paradox:
* The **Content Head** reads 1024 bytes and puts them into `benign_file.txt`.
* The **Parser Head** sees the `0` in the USTAR header and thinks, *"I'm already at the end of the file."* It stays exactly where it is.
Consequently, the **Parser Head** treats the data inside the 1024-byte block as the next set of instructions. If that data looks like a valid TAR header, the library will "discover" and extract a second file that technically doesn't exist according to the archive's global structure.
**The Smuggling Payload:**
The payload is crafted as a sequence of **512-byte blocks**. Here is the layout used in the `malicious-payload` generator:
| Block | Role | Description |
| :--- | :--- | :--- |
| **1 & 2** | **PAX Metadata** | Claims the next file is 1024 bytes long. |
| **3** | **Base Header** | `benign.txt`. **Crucially sets size to 0.** |
| **4** | **Smuggled Header** | `backdoor.sh`. Hidden inside the "data" area. |
| **5** | **Smuggled Data** | The malicious content (e.g., shell aliases). |
| **6 & 7** | **EOF** | Standard null-block termination. |
Because standard tools (like `GNU tar`) follow the `PAX` size correctly, they see **Block 4 and 5** as harmless binary data belonging to `benign_file.txt`. They never "execute" the header in Block 4.
## How is this a vulnerability, and a CVSS 8.1?
How can this crate having a vulnerability be exploited, why does a file being smuggled in an archive matter?
### Supply Chain Injection:
An attacker smuggles malicious files into a build system. Extracting this either for development or on a CI machine, can overwrite legitimate build files, compromising that machine and even tricking the build system to sign malicious files.
### Security Bypass (WAF/AV):
A scanner inspects an .tar, scanning it only in the correct mode, undesired files might be present at extraction but were not scanned
Inspired by [this](https://edera.dev/stories/tarmageddon) writeup