Passar este arquivo para nosso aplicativo vulnerable-extract resulta em:

Enquanto executamos o utilitário tar fornecido pelo nosso SO ((GNU tar) 1.35 neste caso) resulta em:

Note que ele vê que o tamanho do arquivo é 1024

Alternativamente, usando astral-tokio-tar 0.5.6 em vez do abandonado tokio-tar 0.3.1 extrai o arquivo corretamente.

Writeup

CVE-2025-62518 (TARmageddon) é uma vulnerabilidade de segurança encontrada na biblioteca Rust tokio-tar (vulnerabilidade Rust 😮). Este é um erro lógico na forma como os cabeçalhos do formato tar são analisados, permitindo que um atacante contrabandeie arquivos.

A falha existe na lógica de manipulação dos Cabeçalhos Estendidos PAX. Em um arquivo TAR, existem diferentes tipos de cabeçalho:

• USTAR: O cabeçalho padrão contendo nome do arquivo, permissões e tamanho.
• PAX (Tipo x): Um cabeçalho de extensão usado para fornecer metadados (como um tamanho de arquivo muito grande) para o próximo arquivo no archive.

Quando um cabeçalho PAX está presente, um analisador deve resolver o tamanho real do arquivo priorizando os metadados PAX sobre o cabeçalho USTAR padrão.

Mas POR QUE existem 2 tipos de cabeçalhos que têm prioridades para o que parece ser a mesma coisa? Porque o formato TAR é antigo (padronizado em 1988), e USTAR tem suas limitações (tamanho de até 8GB, nome de arquivo de até 256 caracteres). Isso é um problema, então o cabeçalho PAX foi adicionado em 2001 para permitir arquivos maiores e nomes de arquivo mais longos.

Em versões vulneráveis do tokio-tar, o analisador adota corretamente o tamanho do cabeçalho PAX para o leitor de conteúdo do arquivo, mas usa incorretamente o tamanho do cabeçalho USTAR para determinar onde o próximo cabeçalho de arquivo começa.

O cerne do problema é uma incompatibilidade de ponteiro. Quando a biblioteca vulnerável processa um arquivo, ela usa duas 'cabeças' internas diferentes para ler o fluxo:

1. A Cabeça de Conteúdo: Responsável por ler os bytes reais do arquivo e escrevê-los no disco.
2. A Cabeça do Analisador: Responsável por pular os dados do arquivo para encontrar o próximo cabeçalho de arquivo.

Em um arquivo normal, essas duas cabeças concordam. Em TARmageddon, nós as forçamos a discordar. Ao definir o tamanho PAX como 1024 e o tamanho USTAR como 0, criamos um paradoxo:

• A Cabeça de Conteúdo lê 1024 bytes e os coloca em benign_file.txt.
• A Cabeça do Analisador vê o 0 no cabeçalho USTAR e pensa, "Já estou no final do arquivo." Ela permanece exatamente onde está.

Consequentemente, a Cabeça do Analisador trata os dados dentro do bloco de 1024 bytes como o próximo conjunto de instruções. Se esses dados parecerem um cabeçalho TAR válido, a biblioteca 'descobrirá' e extrairá um segundo arquivo que tecnicamente não existe de acordo com a estrutura global do arquivo.

O Payload de Contrabando:

O payload é criado como uma sequência de blocos de 512 bytes. Aqui está o layout usado no gerador malicious-payload:

Como as ferramentas padrão (como GNU tar) seguem corretamente o tamanho PAX, elas veem os Blocos 4 e 5 como dados binários inofensivos pertencentes a benign_file.txt. Elas nunca 'executam' o cabeçalho no Bloco 4.

Como isso é uma vulnerabilidade e um CVSS 8.1?

Como essa crate com uma vulnerabilidade pode ser explorada, por que um arquivo contrabandeado em um archive importa?

Injeção na Cadeia de Suprimentos:

Um atacante contrabandeia arquivos maliciosos para um sistema de build. Extrair isso seja para desenvolvimento ou em uma máquina de CI pode sobrescrever arquivos de build legítimos, comprometendo essa máquina e até enganando o sistema de build para assinar arquivos maliciosos.

Bypass de Segurança (WAF/AV):

Um scanner inspeciona um .tar, escaneando-o apenas no modo correto, arquivos indesejados podem estar presentes na extração, mas não foram escaneados.

Inspirado por este writeup