Skip to content
Tech AI Wire

Um binário strip adulterado pode abrir uma porta em todo o NixOS

Investigadores construíram o ataque trusting-trust de Ken Thompson a partir do GNU strip, e não de um compilador, e abriram portas em quase todos os binários de um instalador NixOS.

Por Tech AI Wire Team

3 min de leitura

XLinkedIn
A terminal running strip on a compiled binary, with the file listing showing it shrink from 5.2M to 1.8M and the ELF header change from not stripped to stripped.

O ataque trusting-trust foi sempre descrito como um problema de compiladores. Um artigo no arXiv mostra que não é. Cinco investigadores construíram uma versão completa do ataque à volta do GNU strip, uma ferramenta de compilação que nunca lê nem escreve código-fonte. Usaram-na para abrir portas em quase todos os binários de um instalador gráfico do NixOS.

Os autores são Julien Malka, Aman Sharma, Martin Monperrus, Stefano Zacchiroli e Théo Zimmermann. O artigo saiu a 27 de julho de 2026.

Qual era o ataque original

Ken Thompson descreveu a ideia em 1984. Adultera-se um compilador para que insira uma porta nos programas que constrói. Ensina-se-lhe também a reconhecer quando está a compilar-se a si próprio, e a colocar a mesma adulteração no novo compilador.

Depois disso, o código-fonte malicioso pode ser apagado. A porta continua a reproduzir-se em cada reconstrução, e ler o código do compilador não revela nada.

A comunidade de segurança tratou isto como uma ameaça própria dos compiladores. É exatamente essa premissa que o artigo ataca.

Porque é que o strip muda o quadro

O GNU strip remove símbolos de depuração de ficheiros compilados. Nunca vê código-fonte. Apenas reescreve ficheiros ELF acabados, que é o formato executável padrão no Linux.

Os investigadores colocaram um strip adulterado na semente binária do NixOS, aquele pequeno conjunto de binários pré-construídos com que uma distribuição arranca antes de conseguir construir seja o que for. A partir daí, a carga copia-se para cada nova geração do strip.

Depois sobrevive até ao ambiente padrão final, já com a semente original fora do grafo de dependências. O ponto de partida adulterado desapareceu, e a porta continua lá.

Correram isto numa revisão real do nixpkgs, fef9403a3e4d, com GNU binutils 2.44 em x86_64. A compilação terminou sem falhas e produziu um instalador gráfico funcional com quase todos os binários comprometidos.

As defesas que não apanham isto

Esta parte merece leitura atenta, porque as respostas habituais falham cada uma à sua maneira.

DefesaPorque falha
Diverse double-compilingO ataque "sits on both sides of the comparison and cancels out"
Compilações reprodutíveisReconstruir com a mesma semente reproduz a carga bit a bit
Compilações arrancáveisSó ajuda na proporção do quão pequena for a semente binária

O diverse double-compiling reconstrói um compilador com um segundo compilador independente e verifica se os resultados coincidem. Os autores notam que "then checks that the two results agree", que é exatamente a verificação que uma carga presente em ambos os caminhos passa.

As compilações reprodutíveis querem "make every build produce bit-for-bit identical output", com um reconstrutor independente a confirmar que um binário corresponde ao seu código. Saída idêntica não é o mesmo que saída limpa.

O artigo aponta, ainda assim, para algo que ajuda. "The full-source bootstrap in GNU Guix reduces the binary seed to a few hundred bytes and rebuilds the whole toolchain from auditable source above it", escrevem os autores. Uma semente menor significa menos material não auditável onde algo se possa esconder.

O que isto significa para programadores

Deixe de identificar a base de confiança com o compilador. Qualquer binário do seu arranque que transforme outros binários está em causa, e isso inclui o strip, os linkers, os arquivadores e os instaladores. A maioria dos modelos de ameaça nunca os listou.

Se depende de compilações reprodutíveis para garantias, perceba ao certo o que elas provam. Provam que a sua compilação é determinista. Não provam que as entradas estavam limpas, e este ataque é deliberadamente determinista.

Se tem NixOS em produção, separe o que aconteceu do que não aconteceu. O ataque foi demonstrado por investigadores sobre uma revisão real, com um pacote de replicação publicado. Não há resposta pública do projeto NixOS, nem indício de que alguém tenha feito isto fora do laboratório.

A alavanca prática é o tamanho da semente. As poucas centenas de bytes do Guix são outra ordem de risco face a uma semente binária convencional. Peça esse número quando lhe disserem que a distribuição é arrancável a partir do código. A governação do código aberto teve um ano cheio, desde a votação da Debian sobre contribuições assistidas por IA até a dissolução da equipa central do Nixpkgs. Isto lembra que a cadeia de compilação também precisa de atenção.

Fontes

  1. Trusting-Trust Attack against an Entire Linux Distribution (via the strip utility) - arXiv
  2. Replication Package - figshare

Artigos relacionados

A process listing on a Kubernetes v1.37 node, showing containerd, kubelet and kube-proxy owned by the kube user while the systemd services still run as root.
Dev Stack

Kubernetes 1.37 promove o modo rootless a beta

O Kubernetes 1.37 promove o KubeletInUserNamespace a beta. O kubelet, os runtimes de contentores, os plugins CNI e o kube-proxy passam a poder correr como utilizador comum.