Copy Fail: O Script que Colocou o Mundo Linux em Xeque

O ecossistema Linux pautou sua segurança por vulnerabilidades complexas, que muitas vezes dependem de condições raras ou configurações específicas. No entanto, a recém-descoberta CVE-2026-31431, apelidada de Copy Fail, desafia essa norma. Trata-se de uma falha lógica direta que permaneceu oculta no coração do kernel por nove anos (desde 2017). Com um script de Python de apenas 732 bytes, é possível obter privilégios de root de forma silenciosa e infalível.

O que torna o Copy Fail um pesadelo invisível para administradores de sistemas é a sua “confiabilidade de 100%”. O exploit utiliza a interface AF_ALG do kernel — habilitada por padrão em quase todas as distribuições modernas — para transformar uma antiga otimização de performance em uma arma de precisão cirúrgica.

1. Além da Sorte: Por que a “Confiabilidade de 100%” é Tão Assustadora

Diferente das vulnerabilidades de Escalada de Privilégio Local (LPE) típicas, o Copy Fail é uma falha de lógica de linha reta (straight-line logic flaw). Para entender o peso disso, precisamos olhar para o passado:

  • Dirty Cow (CVE-2016-5195): Dependia de uma condição de corrida (race condition) do tipo TOCTOU. Exigia múltiplas tentativas e podia causar instabilidade ou travamentos no sistema.
  • Dirty Pipe (CVE-2022-0847): Abusava de sinalizadores (flags) de buffer de pipe, mas era limitada a versões de kernel mais recentes (≥ 5.8).
  • Copy Fail: Executa uma sequência lógica direta que não depende de tempo, tentativas ou offsets de memória específicos de cada versão de kernel.

O exploit funciona de primeira, sem modificações, em distribuições como Ubuntu, Amazon Linux, RHEL e SUSE. Conforme destacado no site oficial copy.fail:

“A maioria das LPEs de Linux precisa de uma janela de corrida ou de um offset específico do kernel. O Copy Fail é uma falha de lógica de linha reta — não precisa de nenhum dos dois.”

Demonstração

Mesmo script, quatro distribuições, quatro shells de root — em uma única tomada. O mesmo binário de exploração funciona sem modificações em todas as distribuições Linux. Veja a demo rápida no link: https://copy.fail

2. O Alvo é a Memória, Não o Disco: A Elegância Furtiva da Corrupção de Page Cache

A vulnerabilidade manipula o Page Cache, a cópia em memória que o kernel utiliza ao carregar binários para execução. O perigo real reside na técnica: ao utilizar a chamada de sistema splice() (que exige Python 3.10+ no script de 732 bytes), o exploit move dados diretamente para o cache.

Essa abordagem confere ao Copy Fail uma furtividade sem precedentes:

  • Bypass de VFS: A escrita ocorre de forma que ignora completamente o caminho do Sistema de Arquivos Virtual (VFS). Como resultado, o sistema nunca marca a página de memória como “suja” (dirty).
  • Invisibilidade Forense: Como o kernel não considera a página “suja”, ele nunca tenta gravar as alterações de volta no disco. Após um reboot ou limpeza de cache, o binário original (como o /usr/bin/su) reaparece intacto. Ferramentas de integridade que analisam apenas o disco físico não encontrarão rastros.
  • Eficácia: Ao escrever apenas 4 bytes controlados no Page Cache do binário su, o atacante engana o kernel para que este execute o processo com privilégios de superusuário sem exigir senha.

3. Uma Otimização que Custou Caro: A Origem da Falha em 2017

A raiz técnica do problema está no módulo algif_aead e, especificamente, em um erro lógico no código authencesn. Em 2017, os desenvolvedores introduziram uma “otimização in-place” que tenta processar dados criptográficos no mesmo buffer para ganhar performance.

O erro ocorre quando essa operação cruza o que chamamos de fronteiras de scatterlists encadeadas (chained scatterlist boundaries). A lógica falha ao não restaurar dados ou ao permitir que 4 bytes controlados sejam escritos fora do limite destinado, atingindo o Page Cache.

A correção (patch) definitiva foi a reversão dessa otimização através do commit a664bf3d603d. No GitHub, a ironia não passou despercebida pelos desenvolvedores, com comentários ecoando o sentimento de toda a comunidade: “se eles soubessem na época…”. Decisões focadas estritamente em performance podem, por vezes, criar dívidas de segurança impagáveis.

4. O Fim do Isolamento: Escape de Containers e Riscos em Multitenancy

O Copy Fail é um divisor de águas para a segurança de nuvem e Kubernetes. Como o Page Cache é compartilhado entre o host e todos os containers, um pod comprometido pode “envenenar” o cache de um binário do sistema usado por outros containers ou pelo próprio host.

Isso transforma uma falha de escalada local em uma primitiva de escape de container. Um atacante em um ambiente isolado pode comprometer o nó inteiro e acessar dados de outros inquilinos (cross-tenant). Os ambientes sob maior risco são:

  • Hosts multi-tenant: Onde múltiplos usuários ou empresas dividem o mesmo kernel.
  • CI Runners e build farms: Sistemas que executam códigos de terceiros (como Pull Requests) de forma automatizada.
  • Cloud SaaS: Plataformas que rodam sandboxes ou scripts fornecidos por clientes.

5. A Nova Era: Descoberta Assistida por IA

A trajetória do Copy Fail também revela o futuro da auditoria de código. Pesquisadores da Xint Code tiveram o insight inicial sobre como o splice() interagia com memórias compartilhadas, mas o trabalho pesado de escala foi feito por Inteligência Artificial.

A IA auditou todo o subsistema de criptografia (crypto/) do kernel Linux em aproximadamente uma hora. Entre diversos bugs identificados, o Copy Fail foi classificado como a descoberta de maior gravidade. Isso prova que a IA agora consegue varrer códigos legados massivos e encontrar falhas críticas que humanos deixaram passar por quase uma década, mudando drasticamente o ritmo do jogo entre atacantes e defensores.

Conclusão: O Que Fazer Agora e o Que Fica para Refletir

A urgência para aplicar as correções depende do seu perfil de uso, mas a atualização do kernel é mandatória.

  1. Atualização: Instale as versões de kernel que incluem o revert do commit a664bf3d603d.
  2. Mitigação Imediata: Se não puder reiniciar agora, desabilite o módulo algif_aead. Para a maioria dos servidores, isso não terá impacto perceptível na performance.
  3. Defesa em Profundidade: Para workloads não confiáveis (containers e CI), bloqueie a criação de sockets AF_ALG via seccomp.

Em um mundo onde scripts de apenas 732 bytes podem derrubar defesas de uma década com 100% de sucesso, somos forçados a questionar: quão seguros estão os alicerces invisíveis sobre os quais construímos nossa infraestrutura digital? A simplicidade do Copy Fail é, sem dúvida, o seu aspecto mais inquietante.

Você também pode gostar:

Veja também temas separados por categorias:

Deixe um comentário

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *