Tempo de Leitura: 5 minutos

A Cadeia de Suprimentos de Software: o Elo Frágil é Humano, Não Técnico

Em março de 2024, Andres Freund, engenheiro da Microsoft, estava medindo desempenho do PostgreSQL em uma máquina Debian sid quando notou algo banal: logins SSH levavam cerca de 500ms a mais do que deveriam, e o sshd consumia CPU demais. Em vez de ignorar, ele abriu o Valgrind, seguiu o rastro até a liblzma e encontrou um backdoor escondido em uma biblioteca de compressão que roda em praticamente toda distribuição Linux do planeta.

O caso ficou conhecido como CVE-2024-3094, recebeu CVSS 10.0 e foi tratado pela imprensa como “o backdoor que quase comprometeu a internet”. Mas a leitura mais útil para quem opera infraestrutura não está no código malicioso. Está em como ele entrou: não por uma falha técnica, e sim por uma operação de engenharia social que durou anos contra um projeto mantido por uma única pessoa exausta.

O que realmente aconteceu no XZ Utils

O XZ Utils era mantido essencialmente por um voluntário, Lasse Collin, sem remuneração e sem sucessão. A partir de 2021, uma conta usando o nome “Jia Tan” começou a contribuir com o projeto, ganhando confiança gradualmente. Em paralelo, contas que pareciam usuários comuns — como “Jigar Kumar” e “Dennis Ens” — pressionavam Collin em listas públicas, reclamando da lentidão das correções e sugerindo que ele precisava de ajuda ou de um novo mantenedor. A pressão coincidiu com um período em que o próprio Collin mencionou estar sobrecarregado.

O resultado: “Jia Tan” recebeu acesso de commit e, com o tempo, controle efetivo sobre os lançamentos. Esse foi o ponto de quebra. Não houve uma vulnerabilidade explorada — houve uma transferência legítima de confiança para um ator malicioso paciente.

A parte técnica veio depois e foi desenhada para escapar de revisão de código. O payload malicioso não existia no repositório Git. Ele só aparecia nos tarballs de release — os pacotes de código já gerados que as distribuições baixam para compilar. O gatilho ficava num arquivo de build (build-to-host.m4) e em arquivos de teste binários ofuscados. Durante a compilação em alvos x86-64 Linux dentro de builds Debian ou RPM, esse código reconstruía a liblzma com a função RSA_public_decrypt sequestrada via resolver IFUNC.

O efeito prático é o que importa para a análise de risco. Em distribuições que faziam o sshd carregar libsystemd (e, por consequência, liblzma), o backdoor permitia execução remota de código pré-autenticação, rodando no contexto do próprio daemon — normalmente root. Não era escalonamento de privilégio: era acesso direto. A ativação não dependia de “passar chaves quaisquer”, e sim de uma assinatura validada com uma chave privada Ed448 específica, que só o atacante possuía. Na prática, era um backdoor com fechadura própria, inútil para qualquer um que não tivesse a chave.

Por que quase nada teria pego isso

As versões comprometidas (5.6.0 e 5.6.1) chegaram a builds de desenvolvimento de Fedora 40/Rawhide, Debian unstable/testing e Kali, na janela aproximada de 26 a 29 de março. Não chegaram em massa a produção por sorte e pela rapidez da resposta — Red Hat, SUSE e Debian reverteram os pacotes em menos de 24 horas após o aviso de Freund.

Vale ser honesto sobre detecção. Um scanner de vulnerabilidade baseado em versão só pega o XZ depois que o CVE foi publicado — antes disso, 5.6.0 era simplesmente a versão estável mais recente, com nome e hash oficiais. Nenhuma assinatura conhecida existia. O que detectou foi um engenheiro experiente reparando em 500ms de latência que não fazia sentido. Isso não é uma estratégia de defesa que se escala, e tratar “intuição de gente boa” como controle é admitir que não havia controle.

SolarWinds não é o mesmo caso

É comum agrupar XZ e SolarWinds como “ataques de cadeia de suprimentos”, mas eles pertencem a categorias diferentes — e isso muda qual defesa se aplica.

No SolarWinds Orion (2020), os atacantes comprometeram o pipeline de build de um fornecedor comercial e injetaram o Sunburst nas atualizações assinadas e legítimas. Milhares de clientes, incluindo agências do governo dos EUA e empresas da Fortune 500, instalaram o software adulterado confiando no canal de atualização. O elo quebrado foi a infraestrutura de compilação e distribuição de um vendor.

No XZ, não houve invasão de pipeline. O atacante se tornou o mantenedor. O elo quebrado foi a governança de um projeto open source de mantenedor único.

A consequência é direta: controle de integridade de pipeline (assinatura de artefato, ambiente de build isolado) teria ajudado contra o SolarWinds, mas seria irrelevante contra o XZ, onde quem assinava era o próprio atacante.

Mantendo a perspectiva

Antes de reorganizar o orçamento de segurança em torno de atores estatais, vale lembrar onde a maioria das violações ainda acontece: patches não aplicados, configurações padrão expostas, credenciais fracas ou reutilizadas e phishing. Um backdoor patrocinado por Estado é uma ameaça real, mas é estatisticamente raro comparado a um bucket S3 público ou a um RDP exposto. Higiene básica continua sendo o melhor retorno por real investido. Cadeia de suprimentos é a camada que você endereça depois de fechar o óbvio, não no lugar dele.

Quais controles de fato mitigam o quê

O erro recorrente em conteúdo sobre o tema é recomendar SBOM como primeira linha de defesa contra o XZ. Um SBOM (Software Bill of Materials) te diz que você executa xz 5.6.0; ele não te diz que 5.6.0 está envenenado. Como a versão maliciosa era a versão oficial, o SBOM só vira útil depois do CVE, para responder rápido “onde isso está rodando?” — função de resposta a incidente, não de prevenção.

Mapeando cada vetor real ao controle que efetivamente o ataca:

Vetor do ataque	Controle que realmente mitiga	Teria pego o XZ?
Takeover de mantenedor único	Governança: mínimo de 2 mantenedores ativos, revisão obrigatória por par, política de sucessão	Provavelmente — o commit access solitário foi o ponto de entrada
Código no tarball que não existe no Git	Builds a partir do Git + diff tarball-vs-repositório	Sim — o payload só vivia no tarball
Build não reprodutível esconde adulteração	Reproducible builds (resultado idêntico, verificável por terceiros)	Sim — quebraria a furtividade
Procedência de artefato não verificável	Assinatura e atestação de procedência (Sigstore, in-toto, SLSA nível 3+)	Parcial — aumenta o custo, mas o atacante era o assinante legítimo
Inventário para resposta pós-disclosure	SBOM	Não previne; acelera a remediação
Comportamento anômalo em runtime	Monitoração de anomalia (CPU, latência, syscalls), EDR	Foi o que de fato funcionou — mas depende de alguém reparar

A pergunta honesta que todo artigo deveria responder e quase nenhum responde: qual desses controles teria detectado o XZ antes do Freund? A resposta desconfortável é que, dos controles mais citados, só dois pegavam de forma confiável — build reprodutível e diff entre Git e tarball. Os demais reduzem superfície ou aceleram resposta, mas não teriam parado o ataque na origem.

Conclusão

O XZ Utils não foi uma história sobre código ofuscado; foi uma história sobre um projeto crítico para a infraestrutura global sustentado por uma pessoa sem apoio, e sobre como a paciência de um adversário transforma essa fragilidade social em acesso root. A lição operacional não é “audite todas as suas dependências” — isso é inviável com milhares de pacotes transitivos. É reconhecer que confiança em open source é uma decisão de risco que precisa de governança verificável: de onde vem o artefato, quem o assinou, e se o que você compila bate com o que está no repositório.

Frameworks como SLSA e SSDF do NIST existem justamente para tornar essas perguntas respondíveis em escala. Mas nenhum framework substitui o investimento que faltou no XZ: financiar e dar sucessão aos mantenedores dos projetos dos quais sua empresa depende. O backdoor mais barato de evitar é aquele que nunca chega a ter um mantenedor desesperado para entregar as chaves.

---

Mais conteúdo técnico sobre cloud, infraestrutura e segurança em t3chtech.com.br.