Dirty Frag: vulnerabilidad LPE (escalada local de privilegios) universal en Linux

 (openwall.com)
2 puntos por GN⁺ 2 시간 전 | 2 comentarios | Compartir por WhatsApp
  • Dirty Frag es una vulnerabilidad universal de escalada local de privilegios que permite obtener privilegios de root en las principales distribuciones de Linux y, debido a que se rompieron el calendario de divulgación responsable y el embargo, todavía no hay parche ni CVE
  • Es una extensión de la misma clase de errores que Dirty Pipe y Copy Fail, y como se trata de un bug lógico determinista, no requiere condición de carrera y tiene una tasa de éxito muy alta
  • La vida útil efectiva de la vulnerabilidad es de aproximadamente 9 años y ya fue probada en distribuciones principales como Ubuntu, RHEL, Fedora y openSUSE
  • Incluso los sistemas que aplicaron la mitigación existente para Copy Fail (lista negra de algif_aead) siguen siendo vulnerables a Dirty Frag
  • Como mitigación temporal, se recomienda eliminar los módulos esp4, esp6 y rxrpc que disparan la vulnerabilidad hasta que lleguen los parches de cada distribución

Resumen general

  • Es una clase de bug que corrompe el miembro frag de la estructura sk_buff, una extensión de la misma clase de errores a la que pertenecen Dirty Pipe y Copy Fail
  • Al encadenar las vulnerabilidades xfrm-ESP Page-Cache Write y RxRPC Page-Cache Write, es posible obtener privilegios de root en las principales distribuciones de Linux
  • Como es un bug lógico determinista, no depende de una ventana de tiempo, por lo que no requiere condición de carrera
  • Incluso si el exploit falla, no provoca kernel panic, y la tasa de éxito es muy alta

Por qué se encadenaron dos vulnerabilidades

  • xfrm-ESP Page-Cache Write ofrece un potente primitivo STORE arbitrario de 4 bytes similar a Copy Fail y está presente en la mayoría de las distribuciones, pero requiere permisos para crear namespaces
  • En Ubuntu, la política de AppArmor puede bloquear la creación de namespaces de usuario sin privilegios, y en ese entorno no se puede disparar xfrm-ESP Page-Cache Write
  • RxRPC Page-Cache Write no requiere permisos para crear namespaces, pero el módulo rxrpc.ko en sí no está incluido en la mayoría de las distribuciones
    • Sin embargo, en Ubuntu el módulo rxrpc.ko se carga por defecto
  • Al encadenar ambas vulnerabilidades, sus respectivos puntos ciegos se compensan mutuamente, haciendo posible obtener privilegios de root en todas las distribuciones principales

Relación con Copy Fail

  • Copy Fail fue la motivación que inició esta investigación
  • xfrm-ESP Page-Cache Write comparte el mismo sink que Copy Fail, pero puede dispararse independientemente de si el módulo algif_aead está disponible
  • Incluso los sistemas que aplicaron la mitigación publicada para Copy Fail (lista negra de algif_aead) siguen siendo vulnerables a Dirty Frag

Alcance del impacto

  • xfrm-ESP Page-Cache Write: desde el commit cac2661c53f3 (2017-01-17) hasta upstream
  • RxRPC Page-Cache Write: desde el commit 2dc334f1a63a (2023-06) hasta upstream
  • La vida útil efectiva de la vulnerabilidad es de aproximadamente 9 años
  • Versiones de distribuciones en las que se completaron las pruebas:
    • Ubuntu 24.04.4: 6.17.0-23-generic
    • RHEL 10.1: 6.12.0-124.49.1.el10_1.x86_64
    • openSUSE Tumbleweed: 7.0.2-1-default
    • CentOS Stream 10: 6.12.0-224.el10.x86_64
    • AlmaLinux 10: 6.12.0-124.52.3.el10_1.x86_64
    • Fedora 44: 6.19.14-300.fc44.x86_64

Medidas de mitigación

  • Debido a que se rompieron el calendario de divulgación responsable y el embargo, no existe parche para ninguna distribución
  • Como mitigación temporal, se proporciona el siguiente comando para eliminar los módulos donde se presenta la vulnerabilidad: 
    sh -c "printf 'install esp4 /bin/false\ninstall esp6 /bin/false\ninstall rxrpc /bin/false\n' > /etc/modprobe.d/dirtyfrag.conf; rmmod esp4 esp6 rxrpc 2>/dev/null; true"
    • Registra los módulos esp4, esp6 y rxrpc en /etc/modprobe.d/dirtyfrag.conf como lista negra y luego los descarga
  • Será necesario aplicar las actualizaciones una vez que cada distribución haya hecho el backport de los parches

Antecedentes de la divulgación

  • Tras coordinarse con los mantenedores de linux-distros@vs.openwall.org, se publicó la documentación de Dirty Frag a petición de ellos
  • El embargo ya se rompió por factores externos, y actualmente no existen parches ni CVE
  • El PoC se publicó en coordinación con linux-distros con el objetivo de proporcionar información precisa, y se prohíbe su uso en sistemas no autorizados

Lecturas relacionadas

2 comentarios

 
GN⁺ 1 시간 전
Comentarios de Hacker News

  • Esto es muy parecido a Copy Fail tanto en la causa raíz como en la forma de explotación.
    Me parece un buen ejemplo de algo que es fácil perder cuando le delegas mucho trabajo a un LLM: la exploración. Siento que hacer investigación de vulnerabilidades con IA bloquea bastante la creatividad. En un flujo donde preguntas y obtienes una respuesta de inmediato, dejas de ver qué más hay alrededor. Es como un genio que te da exactamente lo que pediste y nada más.
    El investigador que descubrió Copy Fail dependió bastante de la IA después de ver algo sospechoso; si hubiera revisado mucho código por su cuenta, probablemente habría tenido más oportunidades de encontrar bugs gemelos como este. Al mismo tiempo, si hubiera usado prompts un poco menos directivos, parece probable que incluso los LLM actuales hubieran encontrado estos bugs. Es un caso bastante curioso de sinergia negativa: trabajaron juntos y el rendimiento empeoró.

    • Si no lo leí mal, no es algo parecido sino la misma causa raíz. Es el problema de los 32 bits altos del Extended ESN de IPsec == el módulo/modo criptográfico authencesn.
      En copy.fail se arregló otra cosa, y la gente le echó la culpa demasiado rápido a AF_ALG.
      [edición: sí, es el mismo problema de authencesn. En el código https://github.com/V4bel/dirtyfrag/blob/892d9a31d391b7f0fccb... authencesn solo aparece en comentarios, pero igual es el mismo problema]
      [edición 2: el problema de RxRPC es aparte; aquí estoy hablando del lado de ESP]
    • También podrías usar un prompt de seguimiento como “encuéntrame bugs parecidos”. Una vez que ya se documentó un caso real, encontrar bugs similares no es tan difícil.
      Entiendo el punto sobre la creatividad. Como cualquier herramienta, la IA puede estrecharte la visión. Es difícil usarla solo como apoyo sin entregarle por completo el flujo de trabajo.
    • No entiendo. Fueron justamente los LLM los que encontraron estos bugs en primer lugar. Y aun así parece que se está presentando ese hallazgo como una señal de que los LLM son malos para descubrir vulnerabilidades.
    • Me pregunto si esto está basado en evidencia o si solo lo están improvisando sobre la marcha.
    • Tomar una vulnerabilidad subyacente parecida a la que encontró la IA, pero no exactamente igual, como lección de que la IA no sabe explorar me parece muy difícil de sostener.
      Salvo que ambas vulnerabilidades se hubieran divulgado juntas como una sola, me pregunto en qué escenario contrafactual diríamos que “exploró lo suficientemente bien”.

  • “Como se rompió el embargo, no hay parches ni CVE para estas vulnerabilidades”.
    Enlace: https://github.com/V4bel/dirtyfrag
    Análisis detallado: https://github.com/V4bel/dirtyfrag/blob/master/assets/write-...
    La parte importante es esta: “Copy Fail fue la motivación para empezar esta investigación. En particular, la escritura en page cache de xfrm-ESP dentro de la cadena de vulnerabilidades Dirty Frag comparte el mismo sink que Copy Fail. Sin embargo, se activa sin importar si el módulo algif_aead está disponible. En otras palabras, incluso en sistemas donde se aplicó la mitigación publicada para Copy Fail, que consiste en poner algif_aead en blacklist, Linux sigue siendo vulnerable a Dirty Frag”.
    La mitigación sería la siguiente, aunque no la probé ni la verifiqué personalmente: “Como se rompió el cronograma de divulgación responsable y el embargo, no hay parche en ninguna distribución. Elimina los módulos que disparan la vulnerabilidad con el siguiente comando”.
    sh -c "printf 'install esp4 /bin/false\ninstall esp6 /bin/false\ninstall rxrpc /bin/false\n' > /etc/modprobe.d/dirtyfrag.conf; rmmod esp4 esp6 rxrpc 2>/dev/null; true"
    En la conversación sobre la mitigación se dice que hace falta reiniciar o, si la máquina ya fue explotada, después del comando anterior habría que ejecutar lo siguiente: sudo echo 3 > /prox/sys/vm/drop_caches

    • En sudo echo 3 > /prox/sys/vm/drop_caches, sudo no hace efecto. sudo ejecuta solo el echo; la escritura real no pasa por sudo.
      Y si la máquina ya fue explotada, para ese punto ya es demasiado tarde. Cualquier cosa en el disco pudo haberse corrompido, así que habría que reconstruir la imagen completa del disco.
    • No puedes usar sudo echo y la redirección así desde un shell sin sudo.
      echo 3 | sudo tee /proc/sys/vm/drop_caches
      o
      sudo sh -c 'echo 3 > /proc/sys/vm/drop_caches'
      Y además corregí el typo de /proc.
    • Como referencia, también se puede mitigar con echo 1 > .... No hace falta vaciar todo; con 1 basta para limpiar solo la page cache.
      Lo probé localmente en Ubuntu 26.04: ejecuté el exploit y obtuve root, configuré la mitigación y, al volver a ejecutar su sin argumentos, me dio root de inmediato sin pedir contraseña. Después de vaciar la page cache, su volvió a pedir contraseña.

  • Necesitamos una forma sencilla de garantizar que solo se carguen módulos del kernel que estén en una whitelist. Ya me cansé de seguir poniendo en blacklist módulos que ni siquiera necesito.

  • Lo pregunto otra vez: ¿por qué en copy.fail toda la culpa se la lleva algif_aead? El que hace estupideces es authencesn.
    authencesn no se arregló, y ahora estamos viendo el resultado. Resulta que se puede llegar a la misma, o probablemente la misma, escritura fuera de límites a través de sockets de red comunes.
    Ojalá se les hubiera ocurrido, pero no pasó.
    [edición: hablo del problema a través de ESP. El problema de RxRPC, según entiendo, es completamente aparte]

  • Si esto de verdad funciona en todas las distribuciones principales, me sigue sorprendiendo lo irresponsables que son los maintainers. ¿Por qué hay funciones opcionales del kernel activadas por defecto si probablemente no le sirven ni al 0.1% de los usuarios?
    Me recuerda a la práctica de las distribuciones Linux de 1999 de instalar por defecto decenas de servicios de red expuestos a internet. Pero ya no estamos en 1999.

    • Es una exigencia bastante grande pedirles a los maintainers de distribuciones que pongan en blacklist funciones específicas porque “seguro no las necesitas” (YAGNI). No pueden saber qué usa cada persona. El usuario siempre puede volver después y ajustar la compilación según lo que realmente quiera.
      Me acuerdo de los primeros años de Linux, cuando corrías make menuconfig y elegías exactamente qué funciones querías en el kernel. La verdad, no tengo ganas de volver a esa época.
      Dicho eso, un objetivo fácil de mejora aquí sería RHEL. RHEL no deja muchos de esos componentes como módulos cargables, sino que los compila directo dentro del kernel, así que mitigaciones como la de copy fail eran imposibles. Quizá sí podrían reducir un poco eso.
    • No hay forma de desactivar componentes que el usuario probablemente no va a usar sin volver muchísimo más difícil usar el sistema. Incluso yo, después de 25 años usando este SO ridículo, no tengo manera de saber qué tengo que encender o apagar para hacer algo.
      Los maintainers de distribuciones Linux son de los mantenedores de software más responsables del planeta. Sus prácticas de seguridad son muchísimo mejores que las de esos gestores de paquetes ridículos de lenguajes de programación: mantienen una lista curada de paquetes, revisan cambios, corrigen bugs, resuelven problemas complejos de empaquetado, hacen backports, usan lanzamientos graduales, distribuyen archivos por mirrors de todo el mundo y verifican criptográficamente todos los archivos. Y no olvidemos que además hacen todo eso gratis.
    • No está activado por defecto. Son módulos opcionales que se cargan cuando hacen falta. Toda la arquitectura del kernel está pensada para compilar las funciones esenciales que necesita el usuario y ofrecer casi todo lo demás como módulos que se cargan bajo demanda.
    • En muchos sentidos, las computadoras que no son móviles siguen viviendo en 1999. Android es mucho más joven y tuvo la oportunidad de integrar control de acceso obligatorio en toda la pila, así que es mucho más seguro que otros sistemas Linux.
    • Para explotar esto tendrías que tener acceso directo a la computadora. Tendría que ser un USB malicioso, o un ataque a la cadena de suministro, o abusar de software conocido que el usuario instalaría voluntariamente o de forma automática. Y además, en la práctica, tendrías que poder ejecutar comandos de terminal casi arbitrarios, lo cual ya sería un compromiso enorme del aislamiento de ese software.
      Si el atacante ya logró todo eso, la situación ya está mal. Que con esto además escale a root sería una de las preocupaciones menores en ese punto.
      Como puso otra persona más abajo: https://xkcd.com/1200/
      Antes de asustarse, la gente debería entender qué es realmente esta vulnerabilidad.

  • Después de tantos años, por fin llegamos al punto de “con suficientes ojos, todos los bugs son superficiales”, y la verdad se siente bastante feo. ¿A partir de ahora habrá que hacer actualizaciones del kernel varias veces por semana?

    • ¿De verdad estás asumiendo que alguien va a meterse a tu casa, encontrar de alguna manera credenciales por defecto y hasta conseguir acceso root?

  • Me pregunto cómo se rompió el embargo. ¿Hubo una filtración, o fue que un tercero lo encontró de forma independiente?

    • Para empezar, el embargo no existe y no puede existir.
      Linux es open source, así que todos los parches que corrigen bugs de seguridad son visibles de inmediato para todo el mundo. No hay forma de evitarlo con la manera en que se desarrolla el kernel. Eso que la gente llama “embargo” es la idea bastante tonta de que, si no escribes de frente “THIS IS A LPE” en la descripción del parche y todos se quedan callados, entonces puedes fingir que la vulnerabilidad no se filtró hasta que salga el mensaje “oficial” en la lista de correo.
      Tal vez antes ese enfoque era medio defendible, pero en la era de los LLM no solo es tonto sino peligroso, porque puedes meter automáticamente los diffs de la lista de correo en un pipeline con el modelo más reciente y hacer que identifique si un parche corrige un problema de seguridad.
    • El enlace al parche apareció en la cuenta de X de alguien, y otra persona lo vio y publicó un exploit funcional en menos de una hora. Puede que se haya apoyado en un LLM, pero fuera del tiempo de respuesta rápido no hay ninguna afirmación demostrada.
      https://x.com/encrypted_past/status/2052409822998392962
    • Lo publicó públicamente un tercero no relacionado.

  • ¿Alguien sabe si Debian es vulnerable? Probé el exploit en máquinas con Debian 12 y Debian 13, pero no logré reproducirlo yo mismo.

    • Lo reproduje en el kernel 6.12.57+deb13-amd64 de Debian 13, es decir Trixie, pero no en el kernel 6.1.0-42-amd64 de Debian 12 Bookworm.
      Para quien en Bookworm no use el stream de seguridad de paquetes de Debian, el kernel 6.1.0-42-amd64 en realidad es inmune a copy.fail. Que también parezca inmune a dirtyfrag es sorprendente. Si todavía no lo han parcheado en el stream de seguridad, podrías elegir una versión de kernel que conserve el commit 2b8bbc64b5c2. Sospecho que ese mismo commit podría estar haciendo que algunas versiones del kernel de Debian 12 sean accidentalmente seguras frente a dirtyfrag.
    • Acabo de probar el exploit en un droplet nuevo de Debian 13 en DigitalOcean y sí funcionó.
    • Lo probé en Debian 13 completamente actualizado y el exploit funciona. También confirmé que la mitigación funciona.

  • Lo ejecuté en un contenedor ubuntu:latest con un nuevo usuario por defecto.
    git clone https://github.com/V4bel/dirtyfrag.git && cd dirtyfrag && gcc -O0 -Wall -o exp exp.c -lutil && ./exp
    Resultado: dirtyfrag: failed (rc=3)
    ¡Buena noticia!

    • Cuando lo ejecuté dentro de un contenedor me dio el mismo resultado, pero al ejecutarlo directamente en el host obtuve un shell. Eso solo demuestra que el exploit no funciona dentro del contenedor. Por lo tanto, puede ser que el contenedor no sea vulnerable, o que el script necesite ajustes para funcionar en un contenedor.
      copy fail sí puede usarse para escapar de contenedores (https://github.com/Percivalll/Copy-Fail-CVE-2026-31431-Kuber...), así que supongo que aquí solo haría falta un pequeño cambio en el exploit.
    • Es difícil considerar a los contenedores una plataforma confiable para esta prueba. Sean normales o no, hay muchas cosas que fallan dentro de contenedores.
 
GN⁺ 2 시간 전
Comentarios en Lobste.rs

  • Vaya semana para administrar servidores Linux compartidos. Aun así, me gusta que esta divulgación vaya directo al grano
    Aunque no entiendo por qué en las guías de mitigación todos ocultan stderr
    Edit: esto dice que fue reportado el 30 de abril, “inspirado” por copy.fail, así que ¿lo descubrieron en menos de un día? Impresionante
    Como alguien con privilegios de sudo en un servidor compartido bastante grande, también me pregunto si sería buena idea compilar el kernel uno mismo incluyendo la menor cantidad posible de módulos. No he analizado a fondo las ventajas y desventajas, pero parece que eso podría haber evitado ambas vulnerabilidades de escalación local de privilegios de esta semana
    Edit 2:

     * 2. rxrpc path  (Ubuntu fallback): if AF_ALG is sandboxed and the ESP
 *    path can't reach the page cache, fall back to the rxrpc/rxkad
 *    nullok primitive that patches /etc/passwd's root entry empty.
 *    PAM nullok then accepts the empty password during `su -`.

    Oh, esto no requiere setuid. Qué bueno que lo incluyeron

    • Yo hago eso en un sistema multiusuario que mantengo, y de hecho pude evitar los dos exploits locales de root de esta semana

  • ¿Sería posible y razonable tomar la lista de módulos del kernel cargados en un sistema en ejecución y usarla como lista permitida para modprobe en ese sistema?
    Tanto CopyFail como DirtyFrag parecen abusar de módulos del kernel que no estaban cargados en ninguno de los sistemas que revisé. Si es así, ¿bloquear módulos que claramente no parecen necesarios no podría mitigar preventivamente algunos ataques?

  • 2026-05-07: Detailed information and the exploit for this vulnerability were published publicly by an unrelated third party, breaking the embargo.
    No entiendo cómo se permite algo así. Se siente realmente absurdo que información de este nivel termine en un entorno tan poco confiable

    • No estoy seguro de si con “un tercero no relacionado lo publicó” se refieren a este caso, pero como referencia, Brad Spengler vio primero el commit de la corrección, detectó la vulnerabilidad de seguridad insinuada por el mensaje del commit, y en las respuestas alguien hizo un exploit con vibe coding
      Cualquier tercero que estuviera observando los commits de Linux podría haber seguido las mismas pistas y creado un exploit
    • La expresión “tercero no relacionado” suena a que no sabían que ese bug estaba bajo embargo
      Aquí el “entorno poco confiable” es internet entero, y en la práctica casi no existe algo que realmente pueda llamarse aislamiento. Siempre fue así, pero ahora solo quedó más claro. También vale la pena leer la publicación reciente de Stefan Eissing sobre cómo un bug de Apache httpd fue redescubierto dos veces antes de que saliera la corrección

  • ¿Hay alguna manera de probar si los módulos afectados realmente no pueden cargarse?
    Con CopyFail me equivoqué al aplicar la mitigación inicial. El nombre del archivo dentro de /etc/modprobe.d/ no terminaba en .conf, y no me di cuenta hasta ejecutar el comando de prueba de https://news.ycombinator.com/item?id=47954159. ¿Habrá comandos parecidos para los módulos esp4/esp6/rxrpc?

    • Intenté cargar los tres módulos con modprobe y me salió el mismo error que la vez pasada
      También hay un código de prueba de concepto adjunto, aunque todavía no he intentado usarlo