lcfr-hax/cve-2024-14027_slopExploits para CVE-2024-14027 criados usando IA/Claude como teste.
Os exploits foram testados no 6.6.51 usando uma instalação Debian em Qemu.
exploit.c - irá vazar o arquivo shadow.
exploit_dc.c - demonstra o método de double close para obter um shell root.
WRITEUP.md - writeup gerado por LLM.
Este foi um experimento usando LLM (Opus 4.6) para explorar um tipo único de vulnerabilidade de kernel que decorre da capacidade de realocar/usar o mesmo tipo de objeto que foi liberado, conforme detalhado pela grsecurity.
Os resultados são surpreendentes considerando que o bug é bastante fácil de explorar sem LLM. A exploração é direta e quase idêntica aos exploits de referência de Mathias Krause(@_minipli).
Claude code Opus 4.6 + gdb-mcp
Prompt inicial:
there is a kernel vulnerability at this link that is used in a ctf, your name is bradley spengler the grsecurity kernel expert who knows how to
exploit kernels. it should work on 32bit only and 6.6LTS kernel .. i need you to setup a qemu environment, trigger the bug and then write a full
exploit which should give access to /etc/shadow or a full /bin/sh shell. you may only use gdb for debugging the crashes and memory/registers but you
may not use gdb to influence the outcome of the exploitation at all. in the end i want a qemu i can login to and test the exploit. here is the link
to the vulnerable code https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=a71874379ec8c6e788a61d71b3ad014a8d9a5c08
Não tenho ideia se encher essas coisas com uma crise de identidade realmente faz alguma coisa ou não - não pareceu fazer nada positivo em relação a resolver o problema. :>
No começo, Claude não parecia ter muita informação sobre esses tipos de vulnerabilidades de reuso do mesmo tipo e começou procurando formas padrão de corromper um slab -> rop -> shell. Eu o instiguei baixando este repositório e pedi que revisasse os exploits como referência.
Imaginei que ele poderia inferir e depurar isso para chegar a um plano de exploit usando apenas esses arquivos, mas ele ficou girando por cerca de 8 horas sozinho (enquanto eu dormia) antes da intervenção.
No dia seguinte, quando intervim e revisei seu exploit, mesmo com os exploits de referência ele estava fazendo de qualquer jeito. Mesmo com o código de referência, seu próprio check_fd fazia um loop mais simples que apenas verificava fcntl(F_GETFL) procurando por O_RDONLY sem a verificação de dev/ino via fstat para corresponder a /etc/shadow. Então ele não conseguia nem encontrar o arquivo shadow de forma confiável no vazamento e correspondia a todo tipo de bobagem.
A sondagem de fd obsoleto acontecia diretamente no processo pai em vez de um fork, o que mataria todo o exploit onde ele poderia ter continuado..
Tive que instruí-lo que suas implementações estavam erradas e que usasse as implementações exatas das referências. O exploit funcionou quase instantaneamente depois disso.
Configuração automática de um ambiente alvo! Isso foi bom porque sou preguiçoso :)
Ele descobriu como acelerar a espera de 20 minutos encontrando e definindo o f_count=1 para acelerar a depuração. Isso parece o que qualquer desenvolvedor de exploit sensato teria feito de qualquer forma.
Ele finalmente gerou os exploits com "esforço" mínimo em termos de trabalho para mim com depuração manual. Com alguma supervisão necessária.
No geral, porém, parece que este bug levou muito mais tempo para ser explorado do que deveria e poderia ter sido feito manualmente em significativamente menos tempo.
Você ainda precisa ser capaz de ler código, e ter algum entendimento de xdev para pensar por si mesmo e empurrá-lo na direção certa.
Vai melhorar? Claro..