lcfr-eth/cve-2024-14027_slopExploits para CVE-2024-14027 creados usando IA/Claude como prueba.
Los exploits fueron probados en 6.6.51 usando una instalación de Debian en QEMU.
exploit.c - filtrará el archivo shadow.
exploit_dc.c - demuestra el método de doble cierre para obtener un shell 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 surge 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
Indicación inicial:
hay una vulnerabilidad del kernel en este enlace que se usa en un ctf, tu nombre es Bradley Spengler, el experto en kernel de grsecurity que sabe cómo explotar kernels. debería funcionar solo en 32 bits y kernel 6.6LTS… necesito que configures un entorno qemu, desencadenes el bug y luego escribas un exploit completo que dé acceso a /etc/shadow o un shell /bin/sh completo. solo puedes usar gdb para depurar los fallos y la memoria/registros, pero no puedes usar gdb para influir en el resultado de la explotación de ninguna manera. al final quiero un qemu al que pueda iniciar sesión y probar el exploit. aquí está el enlace al código vulnerable
No tengo idea si inflar estas cosas con una crisis de identidad realmente hace algo o no; no pareció hacer nada positivo en cuanto 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 estimulé 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 explotación usando solo estos archivos, pero dio vueltas durante unas 8 horas por su cuenta (mientras dormía) antes de la intervención.
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 fcntl(F_GETFL) verificando O_RDONLY sin la comprobación de fstat dev/ino para coincidir con /etc/shadow. Por lo tanto, ni siquiera podía encontrar el archivo shadow de manera confiable en la filtración y coincidía con todo tipo de tonterías.
La consulta de fd obsoleto ocurrió directamente en el proceso padre en lugar de 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 agilizar la depuración. Esto parece lo que cualquier desarrollador de exploits sensato habría hecho de todos modos.
Finalmente generó los exploits con un mínimo "esfuerzo" en términos de trabajo para mí con depuración manual. Con algo de supervisión requerida.
En general, parece que este bug tomó mucho más tiempo de explotar 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..
