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.
3 min de leitura

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.
| Defesa | Porque falha |
|---|---|
| Diverse double-compiling | O ataque "sits on both sides of the comparison and cancels out" |
| Compilações reprodutíveis | Reconstruir com a mesma semente reproduz a carga bit a bit |
| Compilações arrancáveis | Só 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
Artigos relacionados

Debian Code Search elimina a última dependência de cgo
Michael Stapelberg substituiu uma biblioteca em C com 7 anos por Go puro usando o pacote SIMD experimental, e igualou a velocidade da versão em C.

Go 1.27 adiciona métodos genéricos e um encoding/json mais rápido
O Go 1.27 saiu a 19 de agosto de 2026 com métodos genéricos, um motor v2 sob o encoding/json, perfis de fugas de goroutines e assinaturas pós-quânticas.

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.