O que sabemos sobre o backdoor no xz Utils que quase infectou o mundo todo

O caso do backdoor no xz Utils: o que sabemos sobre o incidente que quase infectou o mundo todo

• xz Utils é um utilitário de compressão de dados instalado em quase todos os sistemas operacionais da família Unix, incluindo Linux.
• Ocorreu um incidente em que uma atualização maliciosa quase inseriu um backdoor nesse software.
• Um desenvolvedor da Microsoft descobriu e divulgou esse backdoor, evitando uma crise pouco antes de ele ser incorporado a grandes distribuições Linux como Debian e Red Hat.

Como o backdoor funciona?

• O código malicioso adicionado nas versões 5.6.0 e 5.6.1 manipula o sshd, ou seja, o executável responsável por conexões SSH.
• Alguém com uma chave criptográfica específica pode ocultar código em um certificado de autenticação de login SSH, enviá-lo e executá-lo em um dispositivo com o backdoor instalado.
• Não se sabe qual código foi efetivamente enviado, mas, em teoria, seriam possíveis várias ações, como roubo de chaves criptográficas ou instalação de malware.

Como o backdoor foi inserido

• O backdoor parece ter sido construído ao longo de vários anos.
• Em 2021, um usuário chamado JiaT75 contribuiu pela primeira vez para um projeto de código aberto.
• Em janeiro de 2023, JiaT75 fez sua primeira contribuição ao xz Utils e, depois disso, passou a assumir gradualmente mais funções sob o nome Jia Tan.
• Tan substituiu, no projeto oss-fuzz, as informações de contato de Collins pelas suas e pediu que o recurso ifunc fosse desativado durante os testes.
• Essas mudanças dificultaram a detecção quando Tan introduziu alterações maliciosas no xz Utils.

Distribuições afetadas

• Fedora Rawhide, Fedora 41, Debian testing/unstable/experimental, openSUSE Tumbleweed e MicroOS, Kali Linux e outras incluíam versões do xz com o backdoor.

Opinião do GN⁺

• Esse incidente expõe fragilidades de segurança no ecossistema de código aberto e serve de alerta para a comunidade de desenvolvedores.
• Como o software comprometido é amplamente usado, o caso reforça para usuários e administradores de Linux a importância de atualizações rápidas e verificações de segurança.
• Um caso semelhante foi o hack da SolarWinds, que também mostrou os riscos de ataques à cadeia de suprimentos.
• É necessário verificar a identidade dos desenvolvedores que contribuem para projetos de código aberto e reforçar o processo de revisão de código.
• Espera-se que, a partir deste caso, a importância de auditorias de segurança e de ferramentas de detecção de vulnerabilidades ganhe ainda mais destaque.

[GN⁺]

Opinião do Hacker News

• O OpenSSH é a implementação de sshd mais popular e não se vincula à biblioteca liblzma, mas o Debian e muitas outras distribuições Linux adicionam patches para vincular o sshd ao systemd. O systemd se vincula à liblzma, então o xz Utils pôde afetar o sshd.

• Xz é um programa e biblioteca de compressão de código aberto, útil para escrever seus próprios programas para lidar com dados comprimidos. É usado por muitos outros programas, incluindo o OpenSSH.

• O binutils do GNU também se vincula à liblzma e é ainda mais amplamente usado do que o OpenSSH. Na maioria dos casos, o binutils é usado para compilar o OpenSSH, o sistema operacional em que o sshd roda etc. Isso sugere que os agentes maliciosos escolheram um bom projeto para se infiltrar profundamente no software de código aberto.

• O objetivo é usar um framework de testes padronizado que ajude a escrever mais testes para apoiar a estabilidade do projeto XZ no longo prazo. Muitas funcionalidades ainda não são testadas, então esses testes seriam úteis.

• Não houve muita discussão sobre o mecanismo de linkagem que permite se conectar à função RSA_public_decrypt. Houve muita discussão sobre o que poderia ser alcançado com separação de processos e afins, mas pouco sobre esse redirecionamento de chamada de função. Fica a dúvida se seria possível estabelecer uma forma de conectar componentes importantes em camadas de confiança.

• Dizem que “quase” infectou o mundo, mas, na prática, distribuições Linux populares como Arch, Gentoo e openSUSE Tumbleweed foram distribuídas por semanas com o backdoor incluído, e no Tumbleweed ele definitivamente funcionou. A expressão “quase” é inadequada.

• Há a previsão de que um caso semelhante será encontrado nos próximos 12 meses. Isso começará com mantenedores desconfiando dos commits antigos uns dos outros.

• Lições pessoais tiradas deste incidente:

  • Tarballs de distribuição de código-fonte que incluem código diferente do repositório-fonte são ruins. É preciso abandonar essa prática.
  • Artefatos gerados automaticamente devem sempre ser versionados.
  • Artefatos gerados automaticamente que todo mundo passa batido durante revisão de código podem ser um problema. Se esse tipo de arquivo estiver no repositório, deve haver testes automáticos para verificar se ninguém o adulterou.
  • autotools e a cultura de autotools são ruins.
  • libsystemd causa problemas no ecossistema. As pessoas que criticam o systemd muitas vezes são ignoradas, mas o systemd é grande, complexo, tem muitas dependências, e a maioria dos programas usa apenas uma pequena parte dele.
  • A cultura de que reutilização de código é sempre boa e de que vale a pena depender de uma biblioteca grande para uma funcionalidade pequena está errada. Dependências trazem custo de manutenção e risco de segurança, então isso precisa ser equilibrado com a funcionalidade.
  • Pode ser problemático quando mantenedores de distribuições aplicam patches significativos aos pacotes. Isso acaba criando forks de fato, amplamente usados, sem ninguém que realmente os mantenha.
  • É preciso permitir financeiramente que desenvolvedores consigam trabalhar com OSS. liblzma e xz-utils têm dezenas de milhões de instalações, mas havia um único mantenedor com problemas de saúde mental.
  • Revisão de código e troca de mantenedores agora precisam considerar fatores geopolíticos.

• Agradecimento ao fato de que quem descobriu o problema era um engenheiro da Microsoft que trabalhava no Azure Postgres. Agora passou a gostar do Azure.

• O mantenedor original do xz pode ter transferido a responsabilidade para Jia Tan sem jamais tê-lo encontrado pessoalmente nem falado por telefone. Fica a dúvida se é comum se comunicar apenas por e-mail/GitHub. A expectativa é de que, depois dessa história, os mantenedores de projetos open source fiquem mais cautelosos.

• Embora se pense que esse backdoor foi descoberto cedo, ele pode já ter atingido seu objetivo. Isso é ainda mais provável se os alvos fossem desenvolvedores que usam distribuições rolling release como Kali e Debian.

• A alegação de que Lasse Collin, mantenedor de longa data do xz Utils, não atualizava o software com frequência ou rapidez suficientes parece ter sido um equívoco.