Dirty Frag (CVE-2026-43284) — PoC de Escape de Contenedor en Kubernetes

Una prueba de concepto que demuestra cómo un Pod de Kubernetes predeterminado y sin privilegios puede lograr ejecución de código a nivel de nodo en Amazon EKS explotando la vulnerabilidad de corrupción de caché de páginas del kernel Linux Dirty Frag a través de capas de imágenes de contenedor compartidas.

El primitivo de ataque principal es: cualquier DaemonSet privilegiado que comparta capas de imagen con un contenedor controlado por el atacante puede ser armado para el escape de contenedor. Este PoC utiliza kube-proxy como un ejemplo concreto, pero la técnica se generaliza a cualquier carga de trabajo privilegiada en el clúster.

Validado en Amazon EKS (kernel 6.12.80) — un pod sin privilegios escribe [*] success en el sistema de archivos del host a través del DaemonSet privilegiado kube-proxy:

Aviso legal: Este repositorio se publica únicamente con fines educativos y defensivos. Úselo exclusivamente en sistemas que posea o para los cuales tenga autorización explícita de prueba.

Antecedentes

Dirty Frag (CVE-2026-43284) es una vulnerabilidad de corrupción de caché de páginas del kernel Linux en la ruta de recepción xfrm/ESP. En la ruta afectada, esp_input() puede omitir skb_cow_data() para un skb no lineal sin frag_list, lo que permite que crypto_authenc_esn_decrypt() almacene 4 bytes de datos controlados por el atacante en una página de caché alcanzada a través de splice().

El archivo en disco no se modifica. Los bytes corruptos residen en la caché de páginas del kernel y son observados por lectores posteriores de la misma página de archivo en caché.

Para obtener detalles completos sobre la vulnerabilidad original, consulte V4bel/dirtyfrag.

Principio del Ataque

El ataque explota tres propiedades que comúnmente coexisten en los clústeres de Kubernetes:

1. Corrupción de caché de páginas del kernel (CVE-2026-43284) — un proceso sin privilegios (con soporte de espacios de nombres de usuario) puede sobrescribir las páginas en caché en memoria de cualquier archivo que pueda abrir en modo solo lectura, mediante la carrera de xfrm/ESP splice.
2. Compartición de capas de imagen — los tiempos de ejecución de contenedores (containerd, CRI-O) utilizan sistemas de archivos overlay donde capas de imagen idénticas se asignan a las mismas páginas de caché entre contenedores.
3. DaemonSets privilegiados — muchos clústeres ejecutan DaemonSets con privilegios elevados (privileged: true, hostNetwork: true, capacidades amplias, etc.) que ejecutan periódicamente binarios de su imagen.

Cuando estas condiciones se alinean, un pod sin privilegios puede corromper un binario en una capa de imagen compartida, y un DaemonSet privilegiado en el mismo nodo ejecutará sin saberlo el binario corrupto con sus privilegios elevados — logrando ejecución de código completa a nivel de nodo.

El objetivo de la vulnerabilidad NO se limita a kube-proxy. Cualquier DaemonSet privilegiado (agentes de monitoreo, plugins CNI, recolectores de registros, agentes de seguridad, etc.) cuya imagen de contenedor comparta capas con una imagen controlada por el atacante es un objetivo viable.

Diferencia con Copy Fail

Este proyecto está inspirado en el modelo de explotación de Kubernetes documentado en el PoC de Kubernetes Copy Fail, pero utiliza un primitivo de kernel diferente.

Cómo Funciona

La cadena de ataque tiene tres etapas: corrupción de caché de páginas, propagación entre contenedores y ejecución privilegiada.

1. Parcheo de Caché de Páginas mediante xfrm/ESP

El binario del PoC realiza la siguiente secuencia desde un contenedor sin privilegios:

1. Entra en nuevos espacios de nombres de usuario y de red con unshare(CLONE_NEWUSER | CLONE_NEWNET).
2. Registra muchas Asociaciones de Seguridad xfrm cuyos campos de secuencia altos codifican fragmentos de carga útil de 4 bytes.
3. Abre un binario objetivo de la capa de imagen compartida en modo solo lectura.
4. Utiliza splice() y entrada ESP manipulada para desencadenar la ruta vulnerable del kernel.
5. Repite el primitivo hasta que el contenido de la caché de páginas del binario objetivo contenga la carga útil incrustada.

No se requiere permiso de escritura en el archivo objetivo. El archivo en disco no cambia — solo se corrompe la caché de páginas en memoria.

2. Propagación entre Contenedores mediante Capas Compartidas

Los tiempos de ejecución de contenedores sirven lecturas de capas inferiores overlay a través de la caché de páginas del kernel. Si el contenedor del PoC y kube-proxy comparten el mismo archivo de capa inferior, ambos observan las mismas páginas en caché.

La imagen EKS en este repositorio se construye a partir de:

public.ecr.aws/eks-distro-build-tooling/eks-distro-minimal-base-iptables:2026-03-11-1773190710.2023

Esa base se elige para coincidir con la capa de cadena de herramientas de espacio de usuario kube-proxy de EKS utilizada en el entorno validado.

3. Ejecución Privilegiada por kube-proxy

Cuando kube-proxy ejecuta a continuación un binario de la familia iptables parcheado, el kernel carga las páginas en caché corruptas. La carga útil del PoC monta el dispositivo raíz del host y escribe un archivo marcador en /root/res.

El contenido esperado del marcador es:

[*] success

Diagrama del Flujo de Ataque

┌──────────────────────────────┐     ┌────────────────────────┐     ┌──────────────────────────┐
│  Pod del PoC                 │     │  Caché de Páginas del  │     │  DaemonSet kube-proxy    │
│  contenedor sin privilegios  │     │  Kernel                │     │  contenedor privilegiado │
│                              │     │                        │     │                          │
│  1. unshare user+net ns      │     │                        │     │                          │
│  2. instalar SAs xfrm        │     │                        │     │                          │
│  3. splice binario objetivo  │────▶│  binario de capa       │────▶│  ejecuta binario        │
│     a través de la ruta ESP  │     │  compartida con caché  │     │  parcheado; la carga    │
│                              │     │  de páginas parcheada  │     │  útil se ejecuta con    │
│                              │     │                        │     │  privilegios de nodo    │
└──────────────────────────────┘     └────────────────────────┘     └──────────────────────────┘

Entorno Validado

Amazon EKS

GKE y ACK — Probados, No Explotables con Configuración Predeterminada

He probado esto en clústeres GKE y ACK. Todos fallaron.

El primitivo Dirty Frag requiere la creación de espacios de nombres de usuario (CLONE_NEWUSER) para obtener CAP_NET_ADMIN dentro de un nuevo espacio de nombres de red. Tanto ACK como GKE bloquean esto a nivel de nodo mediante diferentes mecanismos:

• ACK: La restricción a nivel de kernel (user.max_user_namespaces=0) impide completamente la creación de espacios de nombres de usuario sin privilegios.
• GKE: El perfil seccomp predeterminado (habilitado por el indicador --seccomp-default de kubelet) bloquea la llamada al sistema unshare independientemente del límite de espacios de nombres.

Esta es una diferencia clave con Copy Fail (CVE-2026-31431), que no requiere espacios de nombres de usuario y explota con éxito las tres plataformas.

kube-proxy como Ejemplo Concreto

La variante EKS proporcionada parchea los siguientes binarios cuando están presentes:

/usr/sbin/xtables-legacy-multi
/usr/sbin/xtables-nft-multi

Estos binarios son invocados por la cadena de herramientas iptables utilizada por kube-proxy. El momento exacto del disparo depende de la actividad de reconciliación de nodos y servicios. En el entorno validado, la carga útil fue disparada por la reconciliación normal de kube-proxy.

Advertencias importantes:

• kube-proxy solo invoca ipset cuando está configurado en modo ipvs. El modo predeterminado (iptables) no utiliza ipset.
• Algunas distribuciones de Kubernetes administradas ejecutan kube-proxy como un contenedor sin privilegios, lo que limita el impacto del escape.
• El PoC apunta a múltiples binarios (xtables-legacy-multi, xtables-nft-multi) para cubrir diferentes modos de proxy, pero si se invocan depende de la configuración del clúster.

Si kube-proxy no es privilegiado en su clúster, el principio del ataque sigue siendo válido — solo necesita identificar un DaemonSet privilegiado diferente que comparta capas de imagen con una imagen base desde la que pueda construir.

Estructura del Repositorio

.
├── exploit/
│   └── dirtyfrag.c              # Escritor de caché de páginas xfrm/ESP
├── payload/
│   ├── payload-eks.c            # Carga útil nolibc que escribe /root/res en el host
│   └── nolibc/                  # Encabezados nolibc de Linux
├── deploy/
│   └── poc-eks.yaml             # Manifiesto de Deployment EKS sin privilegios
├── scripts/
│   ├── setup-eks.sh             # copia, compila e importa la imagen en un nodo EKS
│   ├── run-poc.sh               # despliega y verifica el marcador
│   └── cleanup.sh              # elimina pod, marcador, páginas en caché e imagen local
├── Dockerfile.eks               # Imagen EKS basada en eks-distro-minimal-base-iptables
├── Makefile                     # objetivos de compilación de payload, exploit, Docker y nerdctl
└── .github/workflows/
    └── docker-publish.yml       # flujo de trabajo de publicación GHCR

Compilación y Uso

# Compilar binario de payload + exploit
make build-eks CC=x86_64-linux-gnu-gcc

# Compilar imagen Docker
make docker-build-eks

# Desplegar (pod sin privilegios)
kubectl apply -f deploy/poc-eks.yaml

# Verificar registros
kubectl logs deployment/dirtyfrag-poc-eks

# Verificar el escape en el nodo
ssh ec2-user@<node-ip> "sudo cat /root/res"
# Esperado: [*] success

El flujo de trabajo de GitHub Actions (.github/workflows/docker-publish.yml) publica la imagen en GHCR al hacer push a main o al crear una etiqueta. Reemplace <owner> en deploy/poc-eks.yaml con el usuario u organización de GitHub que posee el fork.

Limpieza

kubectl delete -f deploy/poc-eks.yaml --ignore-not-found
ssh ec2-user@<node-ip> "sudo rm -f /root/res"
kubectl delete pod -n kube-system -l k8s-app=kube-proxy --force

Versiones Afectadas

• Kernel Linux: Todas las versiones anteriores al parche de CVE-2026-43284 (commit f4c50a4034e6).
• Kubernetes: Cualquier versión que utilice un kernel de nodo sin parchear con espacios de nombres de usuario habilitados. La vulnerabilidad está en el kernel, no en Kubernetes en sí. Kubernetes solo proporciona el contexto de ejecución (capas de imagen compartidas + DaemonSets privilegiados) que eleva el impacto de corrupción local de caché de páginas a escape completo de contenedor.

Mitigación

• Parchee el kernel. Actualice a un kernel que contenga el fix de Dirty Frag, incluido el commit f4c50a4034e6 o el backport del proveedor.
• Deshabilite módulos ESP no utilizados. Bloquee esp4 y esp6 si IPsec ESP no es necesario en los nodos de trabajo.
• Restrinja los espacios de nombres de usuario. Establecer user.max_user_namespaces=0 impide que este PoC obtenga CAP_NET_ADMIN en un nuevo espacio de nombres de red (esto ya es el predeterminado en ACK).
• Utilice perfiles seccomp restrictivos. RuntimeDefault o perfiles personalizados pueden bloquear llamadas al sistema clave de espacios de nombres y redes (esto ya es el predeterminado en GKE).
• Minimice los DaemonSets privilegiados. Evite privileged: true y acceso amplio al host a menos que sea estrictamente necesario.
• Reduzca la compartición de capas con cargas de trabajo privilegiadas. Utilice imágenes base distintas para agentes privilegiados y controle dónde pueden ejecutarse cargas de trabajo no confiables.

Ejemplo de bloque de módulo:

printf 'install esp4 /bin/false\ninstall esp6 /bin/false\n' | sudo tee /etc/modprobe.d/dirtyfrag.conf
sudo rmmod esp4 esp6 2>/dev/null || true

Créditos

• Investigación de Dirty Frag y exploit original: V4bel/dirtyfrag

Referencias

• Dirty Frag - V4bel/dirtyfrag
• Cobertura de LWN
• Discusión de CVE-2026-43284 xfrm/ESP
• PoC de Kubernetes Copy Fail

Licencia

El código del exploit está adaptado de V4bel/dirtyfrag bajo la licencia MIT.

El código de la carga útil se deriva de tgies/copy-fail-c y tiene doble licencia bajo LGPL-2.1-or-later O MIT.

Los encabezados nolibc provienen de la infraestructura de autopruebas del kernel Linux.