Ninguno de los dos fallos por sí solo es totalmente fiable — la vía ESP requiere la capacidad de crear un espacio de nombres de usuario (que el AppArmor de Ubuntu bloquea), y la vía RxRPC necesita rxrpc.ko cargado (que la mayoría de las distribuciones no hacen por defecto). Juntos cubren los puntos ciegos del otro, haciendo que la cadena funcione en prácticamente todas las distribuciones principales.

Hay un proof-of-concept público disponible. Asume que ya está en uso activo.

Qué hace este script

Comprueba tu sistema en busca de las condiciones que hacen posible la explotación, y te dice específicamente por qué estás expuesto — no solo un sí o un no.

No arreglará nada. No explotará nada. Solo te dice la verdad sobre tu sistema.

Requisitos

• Python 3.6+
• Sin dependencias externas — solo stdlib
• No requiere root (intencionadamente — comprobamos lo que un atacante sin privilegios puede ver)

Uso

Eso es todo. Salida con códigos de color, razones específicas para cada hallazgo y un resumen de remediación al final.

Captura de pantalla

[]

Cómo solucionarlo

La solución real es parchear tu kernel. Consulta los avisos de seguridad de tu distribución:

Mientras esperas (o si los parches aún no están disponibles para tu distribución), pon en lista negra los módulos vulnerables:

⚠️ Antes de hacer eso:

• Poner en lista negra esp4/esp6 romperá los túneles IPsec (strongSwan, Libreswan; WireGuard no se ve afectado). No apliques esto en pasarelas VPN.
• Poner en lista negra rxrpc romperá los clientes del sistema de archivos distribuido AFS. Casi nadie lo usa — pero compruébalo primero.

Importante: si tu sistema puede haber sido atacado antes de aplicar la mitigación, el exploit puede modificar binarios en la caché de páginas sin tocar el disco. Las herramientas de integridad de archivos (Tripwire, AIDE) que comprueban sumas de verificación en disco no verán nada raro. Reiniciar limpia la caché de páginas y restaura el estado en disco.

Cómo funciona (la versión corta)

Ambos fallos viven en las rutas rápidas de descifrado in-place del kernel. Cuando un socket buffer lleva fragmentos paginados que no son propiedad privada del kernel — por ejemplo, páginas de pipe adjuntadas mediante splice() o sendfile() — las rutas de recepción de ESP y RxRPC descifran directamente sobre esas páginas respaldadas externamente en lugar de copiar primero.

Un atacante puede dirigir una página de la caché de /usr/bin/su (o de cualquier otro archivo legible) hacia una de estas rutas de descifrado, usando su propia clave para que la "salida descifrada" sea los bytes que elija. El kernel escribe esos bytes directamente en la copia en caché en memoria de su. El archivo en disco no se toca. El kernel nunca marca la página como sucia.

A partir de ese momento, cada proceso que ejecute su ejecuta la versión del atacante — hasta que se ejecute drop_caches o se reinicie.

La variante ESP (cac2661c53f3) y la variante RxRPC (2dc334f1a63a) comparten el mismo sumidero pero tienen requisitos previos diferentes que se cancelan mutuamente, haciendo la cadena fiable en todas las configuraciones principales.

Para el informe técnico completo, consulta V4bel/dirtyfrag.

Cronología de divulgación

Crédito: Hyunwoo Kim (@v4bel) por la investigación original, la divulgación y el PoC.

Aviso legal

Solo detección. Apúntalo a sistemas que estés autorizado a evaluar.