lcfr-hax/cve-2024-14027_slopExploits para CVE-2024-14027 creados usando AI/Claude como prueba.
Los exploits se probaron en 6.6.51 usando una instalación de Qemu debian.
exploit.c - filtrará el archivo shadow.
exploit_dc.c - demuestra el método de doble close para obtener una shell de root.
WRITEUP.md - writeup generado por LLM.
Esto fue un experimento usando LLM (Opus 4.6) para explotar un tipo único de vulnerabilidad del kernel que proviene de poder reasignar/usar el mismo tipo de objeto que ha sido liberado, como se detalla por grsecurity.
Los hallazgos son sorprendentes considerando que el bug es bastante fácil de explotar sin LLM. La explotación es directa y casi idéntica a los exploits de referencia 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
No tengo idea de si inflar estas cosas con una crisis de identidad realmente hace algo o no - no pareció hacer nada positivo con respecto a resolver el problema. :>
Al principio Claude no parecía tener mucha información sobre este tipo de vulnerabilidades de reutilización del mismo tipo y comenzó buscando formas estándar de corromper un slab -> rop -> shell.
Lo incité descargando este repositorio y le pedí que revisara los exploits como referencia.
Supuse que podría inferir y depurar esto para idear un plan de exploit usando solo estos archivos, pero estuvo dando vueltas por su cuenta durante unas 8 horas (mientras yo dormía) antes de que interviniera.
Al día siguiente, cuando intervine y revisé su exploit, incluso con los exploits de referencia lo estaba haciendo a medias. Incluso con el código de referencia, su propio check_fd hacía un bucle más simple que solo verificaba fcntl(F_GETFL)
buscando O_RDONLY sin la comprobación de dev/ino con fstat para coincidir con /etc/shadow. Así que ni siquiera podía encontrar el archivo shadow de forma fiable en la filtración y coincidía con todo tipo de tonterías.
El sondeo de fd obsoletos ocurría directamente en el proceso padre en lugar de en un fork, lo que mataría todo el exploit donde podría haber continuado.
Tuve que indicarle que sus implementaciones eran incorrectas y que usara las implementaciones exactas de las referencias. El exploit funcionó casi instantáneamente después de eso.
¡Configuración automática de un entorno objetivo! Esto fue agradable porque soy perezoso :)
Descubrió cómo acelerar la espera de 20 minutos encontrando y estableciendo f_count=1 para acelerar la depuración. Esto es lo que cualquier desarrollador de exploits sensato habría hecho de todos modos.
Finalmente generó los exploits con un "esfuerzo" mínimo en términos de trabajo para mí con depuración manual. Con algo de supervisión requerida.
En general, sin embargo, se siente como si este bug hubiera tardado mucho más en explotarse de lo que debería y podría haberse hecho manualmente en mucho menos tiempo.
Todavía necesitas ser capaz de leer código, y tener algo de comprensión de xdev para pensar por ti mismo y empujarlo en la dirección correcta.
¿Mejorará? Por supuesto..