Alerta de SlowMist: vulnerabilidad crítica de escalada de privilegios en Linux; desactivar tres módulos como mitigación urgente

El director de seguridad de la información de , 23pds, divulgó el 8 de mayo que los sistemas Linux contienen una grave vulnerabilidad de escalada de privilegios llamada Dirty Frag. Los detalles completos y el código de explotación ya se han publicado. Cualquier usuario local de bajo privilegio puede, sin necesidad de condiciones específicas del sistema, obtener directamente permisos de administrador root en los sistemas afectados. Las medidas de mitigación de emergencia consisten en deshabilitar tres módulos: esp4, esp6 y rxrpc.

Por qué Dirty Frag es tan peligroso: falla lógica, alta tasa de éxito, sin parche

Dirty Frag pertenece a una vulnerabilidad lógica determinista, no a un ataque inestable que dependa de condiciones de carrera. Esto hace que su tasa de éxito sea extremadamente alta y que pueda reproducirse de forma consistente. Los atacantes solo necesitan ejecutar un programa pequeño para obtener de inmediato permisos root en el sistema objetivo. Todo el proceso no provoca un fallo del núcleo y es muy difícil detectarlo mediante la monitorización habitual.

La vulnerabilidad fue presentada por investigadores de seguridad al equipo del núcleo de Linux el 30 de abril, pero antes de que el trabajo de parcheo se completara, un “tercero no relacionado” filtró anticipadamente información detallada y el código de explotación, lo que obligó a levantar la prohibición de seguridad. La comunidad de seguridad en general considera que esto significa que los atacantes maliciosos podrían ya estar explotando activamente esta vulnerabilidad.

Desde el punto de vista técnico, Dirty Frag y la vulnerabilidad Copy Fail que actualmente causa daños generalizados en el ámbito de los servidores Linux comparten un mecanismo similar: realizan el ataque insertando descriptores de caché de páginas dentro de operaciones de copia sin cero. La vulnerabilidad raíz “xfrm-ESP Page-Cache Write” se introdujo con un envío del núcleo de 2017, cac2661c53f3; como las reparaciones de Ubuntu para AppArmor solucionaron esta vulnerabilidad, el PoC enlaza una segunda vulnerabilidad “RxRPC Page-Cache Write” (envío 2dc334f1a63a), asegurando que el ataque también sea efectivo en sistemas Ubuntu.

Alcance afectado: lista de distribuciones Linux principales confirmadas

Distribuciones Linux afectadas confirmadas (parte):

· Ubuntu 24 y Ubuntu 26 (incluye AppArmor, mediante eludir la segunda vulnerabilidad)

· Arch Linux (las versiones actualizadas también se confirma que están afectadas)

· RHEL (Red Hat Enterprise Linux)

· OpenSUSE

· CentOS Stream

· Fedora

· AlmaLinux

· CachyOS (se confirmó que el núcleo 7.0.3-1-cachyos activa el problema)

· WSL2 (Windows Subsystem for Linux) también se confirmó que está afectado

Medidas de mitigación de emergencia: comandos específicos para deshabilitar tres módulos

Antes de la publicación de parches oficiales, el método de mitigación más efectivo es deshabilitar los tres módulos: esp4, esp6 y rxrpc. Estos tres módulos están relacionados con la funcionalidad de red IPSec; a menos que el servidor en sí sea un cliente o servidor IPSec, entonces deshabilitarlos casi no afecta las operaciones normales.

Ejecute los siguientes comandos para deshabilitar los módulos: 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”

Después de completarlo, realice un seguimiento cercano de los avisos de seguridad de cada distribución Linux. Una vez que los parches oficiales se publiquen, implemente inmediatamente las actualizaciones del sistema.

Preguntas frecuentes

¿Dirty Frag ya tiene algún parche oficial?

Hasta la fecha, el organismo oficial aún no ha publicado ningún parche y no se ha visto ningún envío de corrección en el núcleo principal de Linux. Esto se debe a que la prohibición de seguridad se rompió antes de completar la preparación del parche, haciendo que los detalles de la vulnerabilidad se publicaran antes de que el trabajo de reparación estuviera terminado. Los administradores del sistema deben seguir de cerca los avisos de seguridad de las distribuciones Linux y desplegar inmediatamente tras la publicación del parche.

¿Deshabilitar los módulos esp4, esp6 y rxrpc afectará el funcionamiento normal del servidor?

Estos tres módulos están principalmente relacionados con el protocolo IPSec. A menos que el servidor en sí sea un cliente o servidor IPSec (es decir, se usa para comunicaciones de cifrado a nivel de red), deshabilitarlos casi no afectará las operaciones generales, como servicios web, bases de datos o nodos de cifrado. Esta es, por ahora, la solución de mitigación de emergencia más segura y con menor impacto.

¿Por qué se publicó esta vulnerabilidad sin parches?

La práctica habitual de la industria es la “divulgación responsable”: después de que los investigadores de seguridad presenten una vulnerabilidad a los fabricantes, normalmente esperan a que el parche esté listo antes de publicar los detalles. Esta vulnerabilidad se envió el 30 de abril, pero un “tercero no relacionado” filtró con antelación información detallada, rompiendo la prohibición. Los investigadores de seguridad sospechan que los atacantes maliciosos podrían ya estar explotándola activamente, y ese sería el motivo por el que finalmente se levantó la prohibición.