
Exploit de escalada de privilégios no kernel para CVE-2026-31431, abusando da interface AF_ALG para sobrescrever /bin/su e gerar um shell root. Inclui implementação em C e guia de resolução de problemas.
Autor: 0xShe
Idioma / 语言
Guia da Ferramenta de Escalação de Privilégios no Kernel CVE-2026-31431
0x01 Início Rápido
Alguns ambientes alvo não possuem Python instalado, por isso esta lógica de escalação de privilégios foi reescrita em C.
Execute o seguinte comando na sua máquina Linux ou WSL (o uso de -static é recomendado para evitar problemas de versão do GLIBC):
gcc -static exploit.c -o exploit
2. Implantar e Executar
Envie o binário gerado para a máquina alvo:
chmod +x exploit
./exploit
Se o exploit for bem-sucedido, o programa executará automaticamente o su e abrirá um shell root diretamente, sem exigir senha.
0x02 Lógica de Escalação de Privilégios: Como Funciona?
Este exploit abusa de uma falha lógica na interface AF_ALG do kernel Linux (Kernel Crypto API).
Criar um Socket Criptográfico O programa cria um socket AEAD (Autenticação de Criptografia com Dados Associados) usando socket(AF_ALG, ...).
Injeção de Memória (Splice) Ao aproveitar a chamada de sistema splice do Linux, dados de um descritor de arquivo (neste caso /bin/su) podem ser redirecionados diretamente para o buffer criptográfico do kernel.
Sobrescrita do Payload Usando offsets de memória específicos, o exploit substitui parte da lógica de autenticação do /bin/su por um payload de escalação de privilégios (um programa ELF mínimo que executa /bin/sh).
Acionar a Escalação de Privilégios Após o kernel concluir a série de operações criptográficas, o processo su em memória já foi adulterado. Quando system("su") é finalmente executado, o sistema na verdade executa o payload do shell root modificado.
0x03 Guia de Solução de Problemas: Por Que Ainda Pede Senha?
Durante a depuração, se o programa exibir Exploit finished, mas executar o su ainda exigir senha, o problema geralmente é causado por um dos seguintes detalhes.
Este é o ponto de falha mais comum. A chamada sendmsg deve incluir o sinalizador MSG_MORE.
Motivo: Este sinalizador informa ao kernel que mais dados estão por vir e impede que o buffer criptográfico seja finalizado cedo demais.
Consequência: Sem este sinalizador, o kernel fecha imediatamente o contexto criptográfico atual. Como resultado, a injeção splice subsequente não consegue entrar no buffer correto do kernel, tornando a sobrescrita impossível.
O kernel é extremamente rigoroso quanto a alinhamento e verificações de comprimento para dados associados AEAD.
Durante o loop que modifica o /bin/su, cada operação splice deve começar a ler a partir do offset 0.
Alguns sistemas podem já ter patches de segurança silenciosos aplicados. Isso foi confirmado durante testes em várias máquinas — certos alvos já haviam recebido correções não oficiais ou backports.
0x04 Notas
Versão do Kernel: Esta vulnerabilidade afeta principalmente kernels Linux 5.x iniciais (como a versão inicial do Ubuntu 20.04). Se o kernel já foi corrigido, este método não funcionará mais.
Diferenças de Caminho: Diferentes distribuições Linux podem armazenar o su em locais distintos (/bin/su ou /usr/bin/su). O código tenta detectar o caminho correto automaticamente, mas se nenhum dos dois existir, verifique manualmente usando which su e modifique o código de acordo.
Aviso Legal: Este artigo destina-se estritamente a fins de pesquisa técnica e educacional. Não o utilize para atividades ilegais. Os usuários são os únicos responsáveis por quaisquer consequências legais resultantes do uso indevido da ferramenta.