dirtyfrag-arm64

Puerto para arm64/aarch64 de V4bel/dirtyfrag (CVE-2026-43284, CVE-2026-43500).

Probado en Ubuntu 24.04.4 LTS con linux-aws 6.17.0-1013-aws en AWS Graviton (el más reciente disponible al momento de escribir esto).

Informe completo con análisis del bypass de AppArmor, notas de endurecimiento y notas de detección: linnemanlabs.com/posts/porting-dirtyfrag-arm64

⚠️ Las restricciones de userns de AppArmor en Ubuntu no impiden de forma fiable este exploit

Ubuntu tiene dos sysctls de AppArmor:

• kernel.apparmor_restrict_unprivileged_userns
• kernel.apparmor_restrict_unprivileged_unconfined

Ambas pueden evadirse encadenando aa-exec consigo mismo usando perfiles presentes en las imágenes estándar de Ubuntu cloud y del instalador que probé:

aa-exec -p crun -- aa-exec -p crun -- ./dirtyfrag_arm64 --force-esp

Para más información, consulta Two Hops and a Shell para el análisis completo del bypass de AppArmor en Ubuntu.

Qué es diferente en arm64

El PoC original x86_64 usa dos rutas de explotación: una ruta ESP/xfrm que corrompe /usr/bin/su, y un fallback rxrpc/rxkad que corrompe /etc/passwd. En arm64 la ruta rxrpc provoca un oops en el kernel y no se puede usar. La ruta ESP funciona correctamente.

Caída de rxrpc: flush_dcache_page

En x86_64, flush_dcache_page() es una operación nula. x86 tiene cachés de datos/instrucciones coherentes por hardware. En arm64, realiza un mantenimiento real de dcache y desreferencia los metadatos de struct page*. Cuando la ruta criptográfica de rxrpc (rxkad_secure_packet -> crypto_pcbc_encrypt -> skcipher_walk_done) llama a flush_dcache_page sobre una página cuya referencia ha sido manipulada a través de la cadena splice/vmsplice, x86_64 la omite silenciosamente, pero arm64 provoca un fallo de traducción y un oops:

pc : flush_dcache_page+0x18/0x58
lr : skcipher_walk_done+0xbc/0x260
     crypto_pcbc_encrypt+0xe8/0x1c8 [pcbc]
     crypto_skcipher_encrypt+0x48/0xb8
     rxkad_secure_packet+0x108/0x270 [rxrpc]
     rxrpc_send_data+0x264/0x550 [rxrpc]

En los sistemas arm64 que probé, denegar la escritura de uid_map eliminó la ruta ESP funcional. El namespace puede seguir creándose, pero el proceso no puede mapearse a root dentro de él ni obtener las capacidades del namespace necesarias para la configuración de XFRM. El fallback rxrpc no proporcionó una ruta funcional de escalada de privilegios sin namespace en arm64; en su lugar, provocó un oops en el kernel.

Operación solo con ESP

En arm64, solo la ruta ESP fue viable en mis pruebas. Esta ruta requiere crear un namespace de usuario y de red, y luego mapear correctamente al usuario que llama como root dentro de ese namespace. El endurecimiento de la distribución puede romper esa ruta de varias maneras: Ubuntu puede denegar la escritura de uid_map mediante las restricciones de userns de AppArmor; no he probado en Debian/RHEL.

AppArmor: bloqueado por defecto, pero se puede evadir en Ubuntu

En la imagen de Ubuntu 24.04 AWS que probé, apparmor_restrict_unprivileged_userns=1 bloqueó la explotación directa desde mi shell SSH normal al denegar la escritura de uid_map dentro del nuevo namespace.

Sin embargo, con el valor predeterminado apparmor_restrict_unprivileged_unconfined=0, un usuario no confinado puede transicionar a un perfil existente en modo complain (p. ej. runc) mediante aa-exec y evadir la restricción:

aa-exec -p runc -- ./dirtyfrag_arm64 --force-esp

Establecer kernel.apparmor_restrict_unprivileged_unconfined=1 bloquea esta ruta y actualmente se recomienda ampliamente como solución para bloquear todas las rutas. Sin embargo, añadir otro aa-exec también la evita:

aa-exec -p crun -- aa-exec -p crun -- ./dirtyfrag_arm64 --force-esp

Consulta las publicaciones enlazadas anteriormente para más detalles.

Payload específico de la arquitectura

El exploit sobrescribe /usr/bin/su en la caché de páginas con un ELF estático mínimo. El PoC original incrusta un ELF x86_64 con shellcode x86_64. Este port lo reemplaza con un ELF aarch64 equivalente:

• ELF e_machine: EM_AARCH64 (183) en lugar de EM_X86_64 (62)
• Shellcode: instrucciones aarch64 que usan svc #0 en lugar de syscall
• Números de syscall: setgid=144, setuid=146, setgroups=159, execve=221 (vs 106, 105, 116, 59 en x86_64)
• Ancho de instrucción fijo de 4 bytes (vs longitud variable en x86_64), lo que resulta en un payload ligeramente más grande (~216 bytes vs 192)

Compilar y ejecutar

# Clone
git clone https://github.com/linnemanlabs/dirtyfrag-arm64.git

# Build
cd dirtyfrag-arm64
gcc -O0 -Wall -o dirtyfrag_arm64 dirtyfrag_arm64.c -lutil

# Run
./dirtyfrag_arm64 --force-esp

Entorno probado

A fecha de 2026-05-09, el kernel aws más reciente disponible de Ubuntu 24.04 (6.17.0-1013-aws, compilado el 24 de abril) se distribuye sin parches ni para Copy Fail (CVE-2026-31431, divulgado el 29 de abril) ni para Dirty Frag (CVE-2026-43284/43500, divulgado el 7 de mayo).

Mitigación inmediata

Pon en lista negra los módulos vulnerables, aplica el endurecimiento de sistema adecuado para tu distribución.

Poner en lista negra los módulos vulnerables

Seguro en cualquier sistema que no esté usando activamente el modo transporte de IPsec o AFS. Para evitar que se carguen los módulos, pon lo siguiente en /etc/modprobe.d/dirtyfrag.conf:

install esp4 /bin/false
install esp6 /bin/false
install rxrpc /bin/false

Actualizar initramfs

Ubuntu también recomienda regenerar el initramfs para que la lista negra esté presente durante el arranque temprano:

update-initramfs -u -k all
``

### Eliminar los permisos de lectura de los binarios SUID

Bloquea esta clase de ataque a la caché de páginas basado en splice contra esos binarios SUID objetivo. El exploit necesita permisos de lectura del archivo objetivo para `splice()`. Los usuarios aún pueden ejecutar los binarios.

**No implementes esto sin probarlo en tu entorno y en todas tus herramientas.**

```bash
chmod o-r /usr/bin/su

Esto no es una solución, solo una mitigación. Hay muchas más rutas de escalada de privilegios.

Descargar los módulos

Para descargar los módulos del sistema en ejecución:

rmmod esp4 esp6 ipcomp4 ipcomp6 rxrpc 2>/dev/null

Asegúrate de que estén descargados:

grep -qE '^(esp4|esp6|rxrpc) ' /proc/modules \
  && echo "Affected modules are loaded" \
  || echo "Affected modules are NOT loaded"

Vaciar la caché de páginas

Vaciar la caché de páginas debería eliminar los contenidos maliciosos y hacer que los archivos se vuelvan a leer desde el disco.

echo 3 > /proc/sys/vm/drop_caches

Nota: He tenido algunos resultados inconsistentes con esto, pero cuanto más intento reproducirlo, más funciona como se espera. Para este PoC, puedes comprobar el md5sum de /usr/bin/su y, si no coincide, reinicia.

Limpieza después de las pruebas

Ejecuta el paso de vaciar la caché de páginas y luego verifica con:

sha256sum /usr/bin/su

# Or from package manager:

dpkg -V util-linux    # Debian/Ubuntu
rpm -V util-linux     # RHEL/Amazon Linux

Medidas proactivas

Para una postura más proactiva que aborde toda esta clase de vulnerabilidades (no solo los CVE específicos), consulta el análisis completo sobre las restricciones de userns de AppArmor, la prevención de la precarga de módulos y la detección en tiempo de ejecución basada en Tetragon, así como las reglas YARA.

Créditos

• Hyunwoo Kim (@v4bel) - investigación original de la vulnerabilidad, divulgación y PoC x86_64
• SiCk - investigación bypass-pwn sobre el bypass de AppArmor en Ubuntu
• Keith Linneman / LinnemanLabs - port para arm64, análisis de la caída de flush_dcache_page, investigación de AppArmor, notas de detección

Legal

Esta herramienta está destinada únicamente a pruebas de seguridad autorizadas e investigación.

El uso no autorizado contra sistemas que no posees o para los que no tienes permiso explícito de prueba es ilegal y poco ético.

Licencia

MIT. Cópialo, róbalo, modifícalo, aprende de él, comparte tus mejoras conmigo. O no. Es código, haz lo que quieras con él.