O backdoor do xz detectado com NixOS e builds reproduzíveis

• Em março de 2024, foi descoberto um backdoor no software xz, usado em distribuições Linux para descompactar tarballs de código-fonte.
• Esse backdoor foi inserido de forma furtiva ao longo de 3 anos pelo mantenedor malicioso Jia Tan.
• O caso teve grande impacto por permitir execução remota de código e ser extremamente difícil de detectar.
• Ele foi descoberto por acaso por Andres Freund, desenvolvedor de Postgres na Microsoft, enquanto investigava uma queda de desempenho, evitando uma grande catástrofe.

Como o ataque funciona

• O backdoor sequestra o programa ssh para permitir execução remota de código.
• Ele modifica a função RSA_public_decrypt para que, ao fazer login com uma chave RSA específica, o atacante possa executar comandos arbitrários.
• É composto por dois componentes principais:
  1. Um script que instala um arquivo-objeto malicioso como parte do processo de build do xz.
  2. Um procedimento que faz hook na função RSA_public_decrypt.

1. Script de instalação do arquivo-objeto malicioso

• O arquivo-objeto malicioso está escondido em arquivos de teste no repositório git do xz.
• O backdoor só é ativado nos tarballs de release fornecidos pelo mantenedor.

2. Procedimento de hook da função RSA_public_decrypt

• Ele usa o recurso ifunc do glibc para forçar a execução de código em tempo de carregamento dinâmico.
• Quando o ssh é executado, libsystemd e liblzma são carregados, e nesse processo o backdoor executa código arbitrário.

Como evitar o desastre do xz

• Para aumentar a confiabilidade do software de código aberto, é preciso lidar tanto com questões sociais quanto técnicas.
• É necessário melhorar os processos de segurança da cadeia de suprimentos de software.

Build de software a partir de fontes confiáveis

• O ataque foi eficaz porque muitas distribuições fizeram o build do xz usando os tarballs fornecidos pelo mantenedor.
• Sempre que possível, o software deve ser compilado a partir da fonte mais confiável disponível.

Quando a situação permitir...

• NixOS é uma distribuição baseada em um modelo funcional de gerenciamento de pacotes, em que cada pacote é expresso na linguagem de programação funcional Nix.
• O NixOS tem uma cultura de usar arquivos de código-fonte gerados automaticamente pelo GitHub.

Construindo confiança em tarballs de release não confiáveis

• O NixOS precisou usar tarballs fornecidos pelo mantenedor na fase de bootstrap.
• Para reforçar a segurança da cadeia de suprimentos de software, é preciso estabelecer proteções específicas.

1. Comparação de fontes

• É importante verificar se o tarball de código-fonte usado pela distribuição é idêntico ao do GitHub.
• No entanto, muitas vezes os tarballs de release diferem do código-fonte, e isso não é necessariamente um problema.

2. Aproveitar a reprodutibilidade em nível de bits

• Builds reproduzíveis são uma propriedade de projetos de software que geram artefatos idênticos quando compilados duas vezes nas mesmas condições.
• A reprodutibilidade em nível de bits pode ajudar a construir confiança em tarballs fornecidos por mantenedores não confiáveis.

Conclusão

• O incidente do backdoor no xz reforça a importância da segurança da cadeia de suprimentos de software de código aberto.
• Sistemas como o NixOS podem fortalecer a segurança por meio de builds reproduzíveis.

[GN⁺]

Comentários do Hacker News

• O NixOS e os builds reproduzíveis não detectaram o backdoor do xz. O NixOS distribuiu o build malicioso do xz, mas não houve problema porque ele não tinha como alvo o NixOS

  • Os desenvolvedores do NixOS ficaram surpresos ao ver que a versão maliciosa do xz havia sido distribuída aos usuários quando o backdoor foi revelado
  • Teoria e realidade são diferentes, e o motivo de o caso do xz ter sido possível não foi uma fragilidade técnica, mas um problema do “mundo real”. Há dificuldade em reconhecer que não é possível corrigir o mundo real com software

• O autor parece estar focando apenas neste incidente. O caso de Jiatan é um exemplo isolado, e em outros cenários as defesas também podem falhar

  • Como usuário do NixOS, acho muito provável que o NixOS não conseguisse detectar isso. Sem evidências, seria tolice depositar confiança no NixOS

• O NixOS não tem relação com isso, porque o backdoor do xz tinha como alvo RedHat e Debian. Ironicamente, o backdoor foi descoberto por um funcionário da Microsoft

• O artigo menciona que as distribuições deveriam buscar o código-fonte diretamente do VCS (por exemplo, Github), em vez de usar o tarball tradicional de instalação

  • Porém, um mantenedor mal-intencionado pode adicionar blobs binários diretamente ao repositório de código-fonte
  • O autor sugere que o Github é confiável como se verificasse o código, mas na prática o Github não verifica o código

• Se a ideia é focar em incidentes que o NixOS poderia ter evitado, então o foco deveria ser o caso da CrowdStrike. Se fosse possível iniciar com a configuração do dia anterior, a maior parte do problema poderia ter sido mitigada

• O NixOS compila tudo a partir do código-fonte, verifica criptograficamente que o código-fonte usado não foi adulterado e tem dependências de versão entre pacotes. O Debian também tem builds reproduzíveis

  • O problema foi que o sistema de build não removeu os arquivos objeto pré-compilados antes de compilar a partir do código-fonte. Se ninguém revisar o código-fonte, um backdoor pode ser adicionado, e nem o NixOS nem outras distribuições conseguem impedir isso

• “Poderia ter” significa que isso não foi provado, e na prática eles realmente distribuíram isso

• Excelente análise explicativa. Título incorreto e enganoso, talvez “tecnicamente correto”, mas no melhor sentido de “com backdoor incluído”

  • Isso reforça a necessidade e o uso de ferramentas de gerenciamento de build, e de criar explicitamente um grafo de rastreamento causal de como arquivos afetam outros arquivos durante o processo de build, além de construir formas de impor esse grafo ou relatar desvios em relação a um grafo de rastreamento anterior

• Se o PR de Jia Tan tivesse sido aprovado, os artefatos maliciosos poderiam ter ido facilmente para um Github Release, assim como foram para o tarball. É difícil entender em que sentido um Github Release seria uma mitigação de segurança

• A questão é que o tarball de release é diferente do código-fonte

  • Se o tarball fornecido pelo mantenedor tivesse sido gerado honestamente a partir do código-fonte original, é difícil entender por que versões diferentes etc. seriam um problema
  • É preciso fazer com que o tarball gerado possa ser criado a partir do próprio código-fonte, sem excluir nada, e fazer git add & commit. Mesmo assim, seria necessário verificar o histórico de commits, e como isso parecia inofensivo a olho nu, fica a dúvida de como validar isso
  • Se o tarball mantido for gerado a partir do código-fonte do proprietário e não estiver no Github, isso se torna um problema

• Havia mais questões do que apenas enviar arquivos de teste envenenados, mas é difícil entender como o Nix poderia ter evitado isso

  • Se um projeto famoso trocou de liderança, seria preciso observar os commits com atenção e verificar quem é o líder

• Fico me perguntando se entendi o artigo errado ou se deixei passar alguma coisa