
Exploit de escalada de privilegios en el kernel para CVE-2026-31431, que abusa de la interfaz AF_ALG para sobrescribir /bin/su y lanzar una shell root. Incluye implementación en C y guía de solución de problemas.
Autor: 0xShe
Idioma / 语言
Guía de la herramienta de escalada de privilegios del kernel CVE-2026-31431
0x01 Inicio rápido
Algunos entornos objetivo no tienen Python instalado, por lo que esta lógica de escalada de privilegios fue reescrita en C.
Ejecute el siguiente comando en su máquina Linux o WSL (se recomienda usar
-static para evitar problemas de versión de GLIBC):
gcc -static exploit.c -o exploit
2. Desplegar y ejecutar
Sube el binario generado a la máquina objetivo:
chmod +x exploit
./exploit
Si el exploit tiene éxito, el programa ejecutará automáticamente su y
generará un shell root directamente sin requerir contraseña.
0x02 Lógica de escalada de privilegios: ¿cómo funciona?
Este exploit abusa de una falla lógica en la interfaz AF_ALG del kernel de Linux (Kernel Crypto API).
Crear un socket criptográfico
El programa crea un socket AEAD (Autenticación Encriptada con Datos
Asociados) usando socket(AF_ALG, ...).
Inyección de memoria (Splice)
Aprovechando la llamada al sistema splice de Linux, los datos de un
descriptor de archivo (en este caso /bin/su) pueden redirigirse
directamente al búfer criptográfico del kernel.
Sobrescritura del payload
Usando offsets de memoria específicos, el exploit reemplaza parte de
la lógica de autenticación de /bin/su con un payload de escalada de
privilegios (un programa ELF mínimo que lanza /bin/sh).
Activar la escalada de privilegios
Después de que el kernel completa la serie de operaciones criptográficas,
el proceso su en memoria ya ha sido manipulado. Cuando finalmente se
ejecuta system("su"), el sistema en realidad ejecuta el payload del
shell root modificado.
0x03 Guía de solución de problemas: ¿por qué sigue pidiendo contraseña?
Durante la depuración, si el programa muestra Exploit finished pero ejecutar
su aún requiere contraseña, el problema suele deberse a uno de los
siguientes detalles.
Este es el punto de fallo más común. La llamada sendmsg debe incluir la
bandera MSG_MORE.
Razón: Esta bandera le indica al kernel que llegarán más datos y evita que el búfer criptográfico se finalice demasiado pronto.
Consecuencia:
Sin esta bandera, el kernel cierra inmediatamente el contexto
criptográfico actual. Como resultado, la inyección posterior mediante
splice no puede entrar en el búfer correcto del kernel, haciendo
imposible la sobrescritura.
El kernel es extremadamente estricto con la alineación y las comprobaciones de longitud para los datos asociados de AEAD.
ASSOCLEN en el código C se establece en 4 bytes mientras el kernel
espera 8 bytes (o viceversa), el kernel puede lanzar un error de
argumento inválido u omitir silenciosamente la lógica de inyección por
completo.Durante el bucle que modifica /bin/su, cada operación splice debe
comenzar a leer desde el offset 0.
off_su no se restablece explícitamente a 0, splice se comporta de
manera similar a read() y continúa avanzando el puntero del archivo.
En la segunda iteración, los datos inyectados quedan desalineados, lo
que puede corromper su o romper la lógica del exploit.Algunos sistemas pueden tener ya parches de seguridad silenciosos aplicados. Esto se confirmó durante las pruebas en múltiples máquinas: ciertos objetivos ya habían recibido correcciones no oficiales o backports.
0x04 Notas
Versión del kernel: Esta vulnerabilidad afecta principalmente a los kernels Linux 5.x iniciales (como la versión inicial de Ubuntu 20.04). Si el kernel ya ha sido parcheado, este método ya no funcionará.
Diferencias de ruta:
Diferentes distribuciones de Linux pueden almacenar su en ubicaciones
distintas (/bin/su o /usr/bin/su). El código intenta detectar la
ruta correcta automáticamente, pero si ninguna existe, verifíquela
manualmente usando which su y modifique el código en consecuencia.
Aviso legal: Este artículo está destinado estrictamente a fines de investigación técnica y educativos. No lo use para actividades ilegales. Los usuarios son los únicos responsables de cualquier consecuencia legal derivada del mal uso de la herramienta.