La comunidad Linux se enfrenta a una nueva vulnerabilidad crítica de elevación local de privilegios bautizada como Dirty Frag, descubierta apenas una semana después del fallo Copy Fail. Este nuevo problema de seguridad, explicado ampliamente en GitHub, permite que cualquier usuario local sin privilegios consiga acceso de administrador (root) en la mayoría de distribuciones Linux actuales, y lo más preocupante es que, por ahora, no existe parche oficial ni identificador CVE asignado.
Dirty Frag se ha dado a conocer antes de lo previsto tras la rotura de un embargo de seguridad. Un tercero no relacionado con la investigación hizo pública parte de la información, lo que llevó al investigador a publicar detalles técnicos y prueba de concepto antes de que los mantenedores del kernel y las distribuciones tuvieran listas las correcciones. Esto deja a administradores de sistemas con una situación delicada: una vulnerabilidad explotable de forma fiable y sin solución definitiva disponible todavía.
Qué es Dirty Frag y por qué preocupa tanto
Dirty Frag ha sido presentada como la sucesora directa de Copy Fail y forma parte de la misma familia de fallos que Dirty Pipe. Todas estas vulnerabilidades comparten una idea de fondo: aprovechar errores en la gestión de la page cache del kernel, es decir, en la copia en memoria que Linux mantiene de los archivos para mejorar el rendimiento.
En términos prácticos, el ataque consigue que el propio kernel sobrescriba contenido en la page cache de un archivo sin que el atacante tenga permisos de escritura sobre dicho archivo. Esa sobrescritura controlada se convierte en una primitiva de escritura arbitraria que, bien explotada, permite escalar privilegios hasta root con una única ejecución del exploit.
Según el investigador surcoreano Hyunwoo Kim (conocido como @v4bel), Dirty Frag no es un simple bug puntual, sino una clase de vulnerabilidad lógica que amplía la misma familia a la que pertenecen Dirty Pipe y Copy Fail. No depende de condiciones temporales ni de carreras (race conditions), lo que implica que el exploit es determinista, no provoca cuelgues del kernel en caso de fallo y tiene una tasa de éxito muy alta en sistemas vulnerables.
Dos vulnerabilidades encadenadas para lograr root
Una de las características clave de Dirty Frag es que no se basa en un solo fallo, sino que encadena dos vulnerabilidades diferentes del kernel de Linux para lograr un ataque casi universal sobre los sistemas modernos:
- xfrm-ESP Page-Cache Write – Vulnerabilidad en la pila de red IPsec/ESP (función esp_input()), introducida en un commit de enero de 2017 (cac2661c53f3). Permite un almacenamiento de 4 bytes directamente en la page cache, en una posición y con un valor controlados por el atacante.
- RxRPC Page-Cache Write – Fallo en el subsistema RxRPC/rxkad (función rxkad_verify_packet_1()), presente desde junio de 2023. Realiza una escritura de 8 bytes en la page cache aprovechando el descifrado, sin requerir privilegios para crear namespaces, y la clave se puede fuerza bruta completamente desde espacio de usuario.
El primer fallo se encuentra en el subsistema IPsec (xfrm) y se aprovecha cuando un socket buffer no lineal con páginas «spliced» (páginas de la page cache asociadas mediante operaciones como splice(2) o sendfile(2)) esquiva la verificación de copia por escritura (skb_cow_data()). En ese escenario, el camino rápido de descifrado ESP escribe directamente sobre esas páginas, lo que abre la puerta a modificar datos sobre los que un proceso sin privilegios mantiene referencia.
En el caso de RxRPC, la ruta de descifrado aplica un decrypt in-place sobre páginas de la page cache igualmente «ancladas» por el usuario, pero sin necesidad de permisos especiales como la creación de namespaces. El atacante prepara en espacio de usuario un bloque cifrado tal que, al ser descifrado por el kernel, el resultado sea exactamente la escritura deseada en memoria.
Por qué Dirty Frag afecta a casi todas las distribuciones
Por separado, ninguno de los dos fallos cubre todos los escenarios. El exploit xfrm-ESP requiere que un usuario sin privilegios pueda crear namespaces de usuario, algo que en algunas configuraciones de Ubuntu se bloquea con AppArmor. En cambio, el exploit de RxRPC no necesita namespaces, pero el módulo rxrpc.ko no se incluye por defecto en la mayoría de distribuciones corporativas como ciertas versiones de RHEL.
La clave de Dirty Frag está en usar ambos caminos de explotación de forma complementaria. En sistemas donde se permiten namespaces de usuario, se dispara primero la variante ESP; en entornos como muchas instalaciones de Ubuntu, donde la creación de namespaces está limitada pero el módulo rxrpc se carga por defecto, entra en juego la variante RxRPC. De este modo, las «zonas ciegas» de una vía de ataque quedan cubiertas por la otra, logrando un exploit prácticamente universal.
Entre las distribuciones confirmadas como afectadas se encuentran Ubuntu 24.04.4, distintas versiones de RHEL 10.1, CentOS Stream 10, AlmaLinux 10, Fedora 44 y openSUSE Tumbleweed, además de otras plataformas populares como Arch Linux o entornos WSL2 en Windows. En la práctica, esto significa que una gran parte de los servidores y equipos de escritorio Linux en uso pueden ser vulnerables si reúnen los módulos y configuraciones implicadas.
Relación con Copy Fail y otros fallos recientes
Dirty Frag llega justo después de Copy Fail (CVE-2026-31431), que ya forzó a acelerar parches en múltiples distribuciones Linux ante un fallo de elevación de privilegios que se está explotando activamente. Ambos comparten la idea de abusar de la page cache y de rutas rápidas de E/S, pero Dirty Frag tiene una ventaja preocupante: funciona incluso en sistemas donde se han aplicado las mitigaciones de Copy Fail, como el bloqueo del módulo algif_aead o políticas de Lockdown del kernel.
El investigador remarca que Dirty Frag puede dispararse independientemente de que el módulo algif_aead esté habilitado o se haya bloqueado. Es decir, incluso si un servidor en producción ya implementó las recomendaciones para Copy Fail, sigue siendo vulnerable a este nuevo exploit mientras no se actualice el kernel con los parches específicos o se apliquen las medidas temporales de mitigación.
Impacto en entornos empresariales
En el contexto donde Linux es ampliamente utilizado en centros de datos, proveedores cloud y administración pública, Dirty Frag supone un riesgo elevado de escalada lateral dentro de redes internas. Un atacante que logre acceso de usuario normal (por ejemplo, a través de credenciales robadas, una aplicación web vulnerable o un servicio mal configurado) podría conseguir root local de forma inmediata y sin necesidad de explotar condiciones complejas.
Para organizaciones que operan servicios críticos sobre distribuciones como Ubuntu, RHEL, CentOS Stream, Fedora o AlmaLinux, el problema no se limita a un único proveedor: la vulnerabilidad reside en el propio kernel de Linux. Algunos proyectos, como AlmaLinux, ya han comenzado a trabajar en parches tempranos para pruebas, pero a fecha de divulgación no existe todavía una solución oficial ampliamente desplegada.
Este escenario obliga a muchos equipos de seguridad y de sistemas a implementar medidas provisionales, revisar sus inventarios de servidores y estaciones de trabajo, y priorizar aquellos entornos donde haya usuarios con shell interactiva o capacidades para ejecutar binarios en el sistema, y asegurar credenciales (por ejemplo, cambiar la contraseña de root), ya que es justo el vector que Dirty Frag explota.
Dónde se encuentra el fallo en el kernel
A nivel técnico, Dirty Frag reside en las rutas rápidas de descifrado in-place de los módulos de red esp4, esp6 y rxrpc del kernel. Cuando un paquete de red llega envuelto en ESP o a través de RxRPC, el camino de recepción intenta descifrarlo sin copias adicionales de datos para ganar rendimiento.
El problema aparece cuando esos paquetes llevan fragmentos de memoria paginada que no son de propiedad exclusiva del kernel, como páginas de la page cache asociadas por operaciones de splice o MSG_SPLICE_PAGES. En lugar de trabajar sobre un buffer privado, el kernel escribe directamente sobre esas páginas compartidas, que siguen referenciadas por un proceso de usuario sin privilegios. Esto deja expuesto el texto en claro de los datos o, peor aún, permite su corrupción deliberada.
De acuerdo con análisis publicados en listas de correo de seguridad como oss-security y netdev, el commit de enero de 2017 que introdujo la vulnerabilidad xfrm-ESP ya fue también la raíz de un desbordamiento de búfer anterior (CVE-2022-27666), lo que apunta a que el mismo cambio en el código ha generado varios problemas de seguridad en estos años.
Ausencia de parches y rotura del embargo
Dirty Frag fue reportado de forma privada a los mantenedores del kernel de Linux el 30 de abril de 2026. El plan original era mantener la información bajo embargo hasta mediados de mayo para dar margen a preparar parches, coordinar su liberación con las distribuciones y minimizar la ventana de exposición.
Sin embargo, un tercero ajeno al proceso de coordinación publicó detalles del exploit ESP el 7 de mayo, rompiendo el embargo. Ante esta situación, el investigador decidió hacer pública la información completa, incluida una prueba de concepto funcional capaz de obtener root con un solo comando. El resultado es que la mayoría de distribuciones y en el resto del mundo se han visto obligadas a reaccionar sobre la marcha, sin tener soluciones listas.
En el momento de la divulgación, no existían parches oficiales en el árbol principal del kernel ni versiones actualizadas distribuidas por los principales fabricantes. Algunos proveedores, como AlmaLinux, han lanzado parches preliminares para pruebas internas, pero los administradores siguen dependiendo sobre todo de medidas de mitigación a nivel de configuración.
Cómo mitigar Dirty Frag mientras llegan los parches
Ante la ausencia de actualizaciones inmediatas, la recomendación generalizada de la comunidad de seguridad es bloquear o deshabilitar los módulos del kernel implicados en el fallo: esp4, esp6 y rxrpc. Esto evita que las rutas vulnerables puedan cargarse o utilizarse, reduciendo drásticamente la superficie de ataque.
Para la mayoría de sistemas de escritorio y servidores generales, estos módulos No son imprescindibles, ya que se relacionan principalmente con la funcionalidad IPsec (cifrado de tráfico de red) y con RxRPC, un mecanismo de llamada a procedimiento remoto menos habitual en despliegues estándar. No obstante, en entornos que utilizan VPN IPsec basadas en ESP u otros servicios específicos, deshabilitarlos puede afectar a la conectividad y conviene valorar los riesgos.
Una forma rápida y automatizada de aplicar esta mitigación consiste en crear una configuración de modprobe que fuerce la sustitución de los módulos vulnerables por un binario inocuo, y descargarlos si ya estaban activos. Diversas fuentes de seguridad han difundido una línea de comandos similar a la siguiente:
sudo sh -c "printf 'install esp4 /bin/false
install esp6 /bin/false
install rxrpc /bin/false
' > /etc/modprobe.d/dirtyfrag.conf; rmmod esp4 esp6 rxrpc 2>/dev/null; true"
Este comando crea el archivo /etc/modprobe.d/dirtyfrag.conf con reglas que impiden que los módulos esp4, esp6 y rxrpc vuelvan a cargarse, y a continuación intenta descargarlos si estaban ya en memoria. Para la inmensa mayoría de servidores web, bases de datos o aplicaciones de negocio habituales en infraestructuras, no debería causar interrupciones, aunque siempre se recomienda probar primero en entornos de preproducción.
Pruebas de concepto y riesgo de explotación real
Junto a la divulgación pública de Dirty Frag, el investigador ha publicado en GitHub un repositorio con el código de la prueba de concepto, que permite compilar y ejecutar el exploit con un par de comandos. El binario resultante encadena las dos vías de ataque (ESP y RxRPC) y, en sistemas vulnerables, eleva el usuario actual a root de forma inmediata.
Algunos medios técnicos que han analizado el fallo indican que han podido reproducir la vulnerabilidad en distintas distribuciones, incluidas instalaciones actualizadas de Arch Linux y sistemas con kernel principal reciente. Incluso se ha constatado que entornos como WSL2, usados cada vez más por desarrolladores, presentan el mismo comportamiento si el kernel subyacente reúne las condiciones necesarias.
La combinación de un exploit público sencillo de usar y una ventana sin parches disponibles eleva la probabilidad de que grupos maliciosos intenten integrar Dirty Frag en sus cadenas de ataque. Para muchas organizaciones, esto significa revisar con urgencia sus controles de acceso, endurecer la segmentación de redes internas y reforzar la supervisión de actividades sospechosas en servidores Linux.
Respuesta de las distribuciones y próximos pasos
Aunque el anuncio pilló por sorpresa a buena parte del ecosistema, varios proveedores de sistemas Linux han empezado a trabajar en parches específicos para las rutas de descifrado afectadas. El propio investigador remitió el arreglo para la parte de RxRPC a la lista de correo netdev a finales de abril, y se espera que en los próximos días o semanas se integren soluciones en las ramas estables del kernel.
En el caso de distribuciones con fuerte presencia, como Ubuntu, Debian, RHEL, SUSE, openSUSE, Fedora o AlmaLinux, la atención se centra en enviar actualizaciones de kernel debidamente testeadas a través de sus canales de seguridad habituales. Mientras tanto, se insta a administradores y responsables de TI a seguir de cerca los avisos de seguridad y a aplicar las actualizaciones tan pronto como estén disponibles en los repositorios oficiales.
La experiencia reciente con Dirty Pipe, Copy Fail y ahora Dirty Frag pone de manifiesto la necesidad de mejorar las revisiones de seguridad en partes críticas del kernel, especialmente en zonas de alto rendimiento como las rutas rápidas de red y de E/S, donde las optimizaciones agresivas pueden introducir errores sutiles pero muy peligrosos.
La aparición de Dirty Frag, sumada a otros fallos recientes, vuelve a poner el foco en la importancia de mantener una política de actualización ágil y controles de defensa en profundidad en cualquier infraestructura Linux. Aunque todavía no haya parches definitivos para esta vulnerabilidad, deshabilitar los módulos implicados, supervisar los sistemas y prepararse para desplegar rápidamente las futuras actualizaciones del kernel se ha convertido, por ahora, en el mejor plan de contingencia para minimizar el impacto de este nuevo vector de ataque.
from Linux Adictos https://ift.tt/5rSlcij
via IFTTT
Pacosite's Blog 