Comprometimento de servidor SSH causado por backdoor presente no stream upstream do xz/liblzma

• Em uma instalação do Debian sid, foram observados alguns sintomas estranhos relacionados ao liblzma (parte do pacote xz), como aumento do uso de CPU no login via SSH e erros no valgrind
• Foi descoberto que a causa do problema era que o repositório upstream e o tarball do xz estavam infectados por um backdoor. Parte do backdoor existe apenas no tarball distribuído
• O script incluído no tarball é executado no final do configure e, quando certas condições são atendidas, modifica $builddir/src/liblzma/Makefile para injetar código malicioso.

Backdoor no repositório

• A parte principal do backdoor existe em forma criptografada no diretório tests/files dentro do repositório.
• Esses arquivos não eram usados nos testes da versão 5.6.0, e na versão 5.6.1 houve tentativas de corrigir erros do valgrind e falhas causadas pelo backdoor.

Sistemas afetados

• O script do backdoor é chamado pela primeira vez após o configure e modifica o processo de build apenas sob certas condições (por exemplo, sistemas Linux x86-64, uso de gcc e do linker GNU, durante builds de pacotes Debian ou RPM).

Impacto no servidor openssh

• Ao usar uma liblzma instalada com backdoor, o login via SSH fica mais lento.
• O openssh não usa liblzma diretamente, mas algumas distribuições, incluindo o Debian, aplicam patches ao openssh para oferecer suporte a notificações do systemd, e a libsystemd depende de lzma.

Análise do código injetado

• A análise foi feita da perspectiva de um observador que não é pesquisador de segurança nem especialista em engenharia reversa.
• O backdoor intercepta a execução por meio de um ifunc resolver e, durante a inicialização do sshd, resolve símbolos para alterar o símbolo RSA_public_decrypt para o seu próprio código.

Impacto no sshd

• RSA_public_decrypt@....plt é alterado para apontar para o código do backdoor, fazendo com que esse código seja chamado durante o login com chave pública.
• Presume-se que isso permita contornar a autenticação ou possibilite execução remota de código.

Relato do bug

• O bug não foi reportado porque há suspeita de envolvimento do repositório upstream.
• A Red Hat atribuiu o identificador CVE-2024-3094 a esse problema.

Detecção de instalações vulneráveis

• Foi fornecido um script para detectar se o binário ssh do sistema é vulnerável.

[depth221]

Tudo o que eu sei sobre o backdoor no xz
Texto escrito por Andres Freund, que descobriu esse backdoor.

[edunga1]

É impressionante como isso parece ter sido executado de forma tão planejada;; o processo parece um drama.

[carnoxen]

Mesmo esquartejado, ainda sai barato.

[roxie]

Por quê?

[keepworking]

Como foi um ato de inserir intencionalmente um backdoor em software de código aberto... durante esse processo, também houve ações como conduzir discretamente uma campanha de manipulação da opinião pública
Já houve antes casos de inserir vulnerabilidades de forma maliciosa no kernel do Linux, então é realmente lamentável

[roxie]

Ah, acho que agora entendi a nuance. Obrigado.

[GN⁺]

Comentários do Hacker News

• Links relacionados:

  • Xz: Disable ifunc to fix Issue 60259
  • FAQ on the xz-utils backdoor
  • Everything I Know About the XZ Backdoor

• Resumo:

  • O autor do backdoor passou várias semanas se comunicando para tentar adicionar o xz 5.6.x ao Fedora 40 e 41. Houve colaboração para resolver o problema no valgrind causado por esse backdoor, mas no fim descobriu-se que o próprio backdoor era a causa do problema. Depois que o período de embargo foi quebrado por engano, foi necessário corrigir a questão com urgência.
  • Um dos autores do backdoor desativou diretamente no oss-fuzz uma funcionalidade da qual o backdoor dependia, evitando assim uma descoberta acidental.
  • O autor do backdoor adicionou um arquivo SECURITY.md ao projeto xz-java. O arquivo orienta que, ao encontrar uma vulnerabilidade de segurança, ela não seja divulgada publicamente e seja reportada em privado. Sob outra perspectiva, isso pode ser interpretado como uma tentativa de ganhar tempo para ajustar seu exploit e aproveitar os alvos.
  • O openssh não usa diretamente a liblzma, mas o Debian e várias outras distribuições aplicam patches ao openssh para suporte a notificações do systemd. Com isso, a libsystemd passa a depender da liblzma, criando dependências adicionais para daemons críticos de segurança como o openssh e aumentando o risco de ataques à cadeia de suprimentos.
  • Pontos principais para quem está em pânico verificar:
    • Se está usando uma versão recente da liblzma5 (5.6.0 ou 5.6.1). Ela foi adicionada no último mês aproximadamente.
    • Se está usando uma distribuição Linux baseada em Debian ou RPM. Isso parece ter sido uma tentativa de dificultar a engenharia reversa.
    • Se executa o OpenSSH sshd no systemd. Em algumas distribuições, o OpenSSH com patch usa a libsystemd para logging, o que acaba puxando a liblzma5 vulnerável.
    • O Debian testing já tem a versão 5.6.1+really5.4.5-1, que na prática é a versão anterior 5.4 reempacotada como se fosse uma versão nova.
  • Se alguém quisesse esconder algo suspeito no GNU autoconf, esconderia ali em vez de em um script no estilo "curl | sh". O distribuidor deste incidente já havia sido responsável por releases antes e começou a fazer commits em 2022. Há commits com muitas mudanças reais, além de contribuições em projetos relacionados como o libarchive. Foi necessário muito esforço para inserir o backdoor.
  • Alguns anos atrás, ele escreveu uma biblioteca Go que encapsula o código C do xz para permitir compressão xz em Go. Cerca de uma semana atrás, recebeu o primeiro PR nesse repositório para atualizar para a 5.6.1. Isso veio de uma conta do GitHub diferente da conta upstream.
  • Ele gosta quando contribuidores que não são pesquisadores de segurança nem engenheiros de reversão escrevem textos técnicos. O relatório que resume sua descoberta é visto como um excelente modelo para contribuidores fora do mundo tradicional de debugging, onde costuma haver relutância em compartilhar.
  • Ao imaginar uma tentativa de backdoor mais sofisticada contra o xz(1), é provável que ela não tivesse sido descoberta tão rapidamente. O xz é usado em praticamente todo lugar. Seria possível criar um xz que modificasse seletivamente apenas pequenas partes de arquivos como tarballs .tar.xz de software usados como base de certos processos de build, mirando tarballs que distribuem binários pré-compilados, e não tarballs de código-fonte.