Copy.Fail (CVE-2026-31431): Mais do que uma Escalada de Privilégios (LPE)

A recente CVE-2026-31431, apelidada de Copy.Fail, está ganhando atenção na comunidade de segurança, e este artigo visa detalhar por que ela representa algo mais do que uma simples escalada de privilégios (LPE). A vulnerabilidade, descoberta por Anton Kirsanov, permite a injeção de código em processos Linux em execução, abrindo novas frentes de ataque e desafiando os mecanismos de detecção existentes.

Copy.Fail se manifesta como um primitivo de injeção de processo através do cache de páginas. O Proof of Concept (PoC) original demonstra a modificação de um binário setuid antes do execve, resultando em acesso root. Outro PoC público substitui o ID do usuário atual por 0000, concedendo privilégios elevados. No entanto, a análise aprofundada revela propriedades adicionais que tornam essa vulnerabilidade ainda mais significativa. A principal delas é a capacidade de modificar o código de um processo em execução sem a necessidade de ptrace ou qualquer interação direta com o processo-alvo, e sem o uso de execve para executar o código injetado. A modificação é invisível para ferramentas de monitoramento comuns, como inotify, e não atualiza o mtime do arquivo, tornando a detecção extremamente difícil.

A técnica de injeção de código em tempo real (Live Code Injection) explora a forma como arquivos executáveis são carregados via mmap(file, MAP_PRIVATE, PROT_READ|PROT_EXEC). O segmento .text é acessível apenas para leitura, e o processo não realiza gravações diretas nele. A vulnerabilidade Copy.Fail manipula essa página do cache de páginas através do subsistema criptográfico (AF_ALG + splice + authencesn scratch write). O processo afetado, ao executar a próxima instrução na página modificada, enxerga o código alterado. Essa abordagem é similar ao Dirty Pipe (CVE-2022-0847), que também utilizava splice para escrever no cache de páginas. A diferença reside no fato de que o Dirty Pipe modificava os flags do buffer do pipe, enquanto o Copy.Fail utiliza scratch write em authencesn. A exploração da capacidade de compartilhamento do cache de páginas entre o cache de arquivos e os mapeamentos de memória dos processos é o cerne da vulnerabilidade. Max Kellerman, ao divulgar o Dirty Pipe em 2022, observou que a escrita no cache de páginas permite a "injeção de código em processos arbitrários". O Copy.Fail concretiza essa possibilidade, revelando que as soluções de detecção Linux padrão não estão preparadas para lidar com essa ameaça.

O PoC, disponível em https://github.com/kvakirsanov/CVE-2026-31431-live-process-code-injection/blob/main/copy_fail_inject_poc.py, demonstra a injeção de código em um processo em execução. Os testes foram realizados em Debian 6.1.0-25, x86_64 e aarch64, sem a necessidade de ptrace ou acesso a /proc/PID/mem. Em sistemas vulneráveis, essa técnica representa um método eficaz de injeção de código. O stack de detecção para injeção de processo não cobre esse caso específico, indicando a necessidade de monitorar AF_ALG, além de ptrace. A natureza furtiva da vulnerabilidade agrava o problema.

Diversos mecanismos de proteção são contornados por Copy.Fail. Abordagens documentadas, como MITRE DET0203, DET0508, Tracee TRC-1024 e o guia Akamai, monitoram ptrace, /proc/PID/mem e process_vm_writev. A injeção no cache de páginas não utiliza nenhum desses mecanismos, pois o processo atacante interage apenas com o arquivo (socket AF_ALG + splice). Portanto, a detecção deve incluir o monitoramento de sockets AF_ALG.

O YAMA ptrace_scope não é aplicável, pois ptrace não é usado. Seccomp depende do perfil, e os perfis padrão do Docker e Kubernetes PSS Restricted não bloqueiam AF_ALG (conforme confirmado pela Juliet Security). Um perfil que bloqueia explicitamente socket(AF_ALG, …) pode prevenir o ataque. As regras auditd ptrace/procfs não são acionadas, pois ptrace e /proc/PID/mem não são utilizados, tornando a modificação invisível para o monitoramento de arquivos. Copy.Fail não invoca write() no arquivo alvo. A modificação do cache de páginas ocorre dentro do subsistema criptográfico via scatterwalk_map_and_copy(). inotify não detecta a modificação, gerando apenas eventos normais de leitura (OPEN, ACCESS, CLOSE_NOWRITE), sem o evento MODIFY. O mtime e ctime não são atualizados.

A reversibilidade da modificação do cache de páginas é possível através de posix_fadvise(fd, 0, 0, POSIX_FADV_DONTNEED), que faz com que o kernel descarte as páginas do cache, carregando os dados originais do disco na próxima leitura. Esse processo é realizado sem privilégios. Após o descarte, o conteúdo do arquivo é restaurado, os hashes correspondem à linha de base, o mtime não muda e inotify não é acionado. O ciclo completo (injeção → uso → apagamento) parece ser amplamente invisível para as ferramentas de monitoramento, tornando a detecção e a resposta a incidentes ainda mais desafiadoras.