Copy Fail (CVE-2026-31431) — PoC de Escape de Contenedor en Kubernetes

Una prueba de concepto que demuestra cómo un contenedor completamente sin privilegios puede lograr ejecución de código a nivel de nodo en Kubernetes explotando el bug de corrupción de page-cache del kernel Linux CVE-2026-31431 a través de capas de imagen de contenedor compartidas.

Aviso: Este repositorio se publica únicamente con fines educativos y defensivos. Úsalo exclusivamente en sistemas que poseas o para los que tengas autorización explícita de prueba.

Antecedentes

CVE-2026-31431 ("Copy Fail") es una vulnerabilidad del kernel Linux en la ruta de Copy-on-Write (CoW) del page-cache. Una condición de carrera en splice de AF_ALG permite que un proceso sin privilegios corrompa las páginas del page-cache de un archivo de solo lectura. La corrupción persiste en el page-cache del kernel y es visible para todos los procesos que posteriormente lean o ejecuten el archivo, incluidos procesos en otros contenedores o en el host.

Para más detalles sobre la vulnerabilidad original, consulta copy.fail.

Cómo Funciona

La cadena de ataque tiene tres etapas: corrupción del page-cache, propagación entre contenedores y ejecución privilegiada.

1. Corrupción del Page-Cache mediante Condición de Carrera en splice de AF_ALG

El subsistema AF_ALG (cripto) del kernel expone una interfaz basada en sockets para operaciones criptográficas en espacio de usuario. El exploit abusa de una condición de carrera en cómo el kernel maneja splice() desde un archivo hacia un socket AF_ALG:

Abre el binario objetivo (p. ej. /usr/sbin/ipset) en modo solo lectura.
Crea un socket AF_ALG AEAD vinculado a authencesn(hmac(sha256),cbc(aes)).
Envía un pequeño fragmento de payload a través del socket AF_ALG con MSG_MORE, indicando al kernel que espera más datos.
Ejecuta splice() del contenido del archivo objetivo desde un fd → pipe → socket AF_ALG.
Debido al bug de CoW, el kernel escribe los bytes del payload del atacante en las páginas del page-cache del archivo objetivo en lugar de aislarlos correctamente.

El exploit repite esto para cada ventana de 4 bytes hasta que todas las páginas cacheadas del binario objetivo se sobrescriben con un payload personalizado.

No se necesita permiso de escritura sobre el archivo. El archivo en disco no cambia; solo se corrompe el page-cache en memoria.

2. Propagación entre Contenedores mediante Compartición de Capas de Imagen

Los runtimes de contenedores (containerd, CRI-O) usan sistemas de archivos overlay. Cuando dos contenedores comparten la misma capa de imagen, el kernel sirve sus lecturas de archivos desde las mismas páginas del page-cache.

Esta imagen PoC está construida FROM registry.k8s.io/kube-proxy:v1.35.2. El DaemonSet de kube-proxy en cada nodo de Kubernetes usa exactamente la misma capa base. Como resultado, /usr/sbin/ipset en ambos contenedores se asigna al mismo conjunto de páginas del page-cache.

Cuando el contenedor PoC sin privilegios corrompe el page-cache de ipset, la corrupción es inmediatamente visible para el contenedor privilegiado de kube-proxy en el mismo nodo, sin comunicación alguna entre contenedores.

3. Ejecución Privilegiada por kube-proxy

kube-proxy se ejecuta como un DaemonSet privilegiado con hostNetwork: true. Invoca periódicamente /usr/sbin/ipset para gestionar reglas de iptables/ipset. Cuando ejecuta ipset la próxima vez, el kernel carga las páginas corruptas del page-cache, ejecutando el payload del atacante con todos los privilegios de kube-proxy:

Root completo en el nodo
Todas las capabilities
Acceso a los namespaces del host

El payload de este PoC (payload/payload.c) simplemente monta el sistema de archivos raíz del host y escribe un archivo marcador en /root/res como prueba de ejecución de código a nivel de nodo.

Diagrama del Flujo de Ataque

┌──────────────────────────┐     ┌──────────────────────────┐
│   Contenedor PoC         │     │   Contenedor kube-proxy  │
│   (sin privilegios)      │     │   (privilegiado)         │
│                          │     │                          │
│  1. Abre /usr/sbin/ipset │     │                          │
│     (solo lectura)       │     │                          │
│                          │     │                          │
│  2. Condición de carrera │     │                          │
│     en splice de AF_ALG  │     │                          │
│     corrompe page-cache  │     │                          │
│          │               │     │                          │
└──────────┼───────────────┘     └──────────────────────────┘
           │                                  │
           ▼                                  │
  ┌─────────────────────┐                     │
  │  Page-Cache Kernel  │                     │
  │  /usr/sbin/ipset    │◄────────────────────┘
  │  (CORRUPTO)         │     3. kube-proxy ejecuta ipset
  │  contiene los bytes │        → carga páginas corruptas
  │  del payload del    │        → el payload se ejecuta como
  │  atacante           │           root en el host
  └─────────────────────┘

Estructura del Repositorio

.
├── cmd/copyfail/main.go          # Punto de entrada; incrusta el payload compilado
├── internal/
│   ├── exploit/
│   │   ├── exploit.go            # Exploit principal: bucle de condición de carrera en splice de AF_ALG
│   │   └── patch.go              # Divide el payload en ventanas de parcheo de 4 bytes
│   └── alg/
│       └── alg.go                # Abstracción del socket AF_ALG AEAD
├── payload/
│   ├── payload.c                 # Payload de validación (monta fs del host, escribe marcador)
│   └── nolibc/                   # Mini libc del kernel para payloads estáticos sin dependencias
├── deploy/
│   └── poc.yaml                  # Manifiesto de Deployment de Kubernetes
├── Dockerfile                    # Construido FROM kube-proxy para compartir capas de imagen
├── Makefile                      # Orquestación de compilación
└── docs/                         # Evidencia de validación de ACK (Alibaba Cloud)

Requisitos Previos

Go 1.25+
Un compilador cruzado para el payload nolibc (por defecto: x86_64-linux-gnu-gcc)
Docker / Buildx
Un clúster de Kubernetes que ejecute kube-proxy como DaemonSet con imagePullPolicy: IfNotPresent (el valor por defecto)
Kernel Linux anterior al parche de CVE-2026-31431

Compilación

# Compilar payload + binario Go
make build

# Compilar imagen Docker
make docker-build

# Compilar y publicar en GHCR
make docker-push IMAGE=ghcr.io/<tu-usuario>/copy-fail-poc TAG=latest

Para objetivos arm64:

make build CC=aarch64-linux-gnu-gcc GOARCH=arm64

Uso

Desplegar el PoC

kubectl apply -f deploy/poc.yaml

El Deployment crea un único pod sin privilegios. Este:

Ejecuta /bin/copyfail -target /usr/sbin/ipset para corromper el page-cache.
Permanece en reposo indefinidamente para que el pod siga activo para observación.

Verificar el Escape

Después de que kube-proxy ejecute ipset la próxima vez (esto suele ocurrir en cuestión de segundos debido a su bucle de reconciliación, o en su próximo reinicio), verifica el nodo:

# Conéctate por SSH al nodo, o usa un pod de depuración privilegiado
cat /root/res
# Salida esperada: [*] success

La presencia de /root/res en el sistema de archivos del host demuestra que el código proporcionado por el atacante se ejecutó con privilegios a nivel de nodo, escrito desde el contexto del contenedor privilegiado de kube-proxy.

Limpieza

kubectl delete -f deploy/poc.yaml

# En el/los nodo(s) afectado(s), elimina el marcador y reinicia kube-proxy:
rm -f /root/res
systemctl restart kubelet   # o elimina el pod de kube-proxy para forzar un nuevo pull

¿Por qué kube-proxy + ipset?

kube-proxy es un objetivo ideal porque:

Está presente en todos los nodos — se ejecuta como DaemonSet.
Es altamente privilegiado — privileged: true, hostNetwork: true.
Incluye ipset en su imagen — ipset es un binario setuid usado para la gestión de iptables.
Usa imagePullPolicy: IfNotPresent — una vez que la imagen del atacante se descarga y comparte la misma capa base, las páginas del directorio inferior del overlay se comparten.

Cualquier DaemonSet privilegiado cuya imagen contenga un binario predecible podría ser atacado de la misma manera.

Personalización del Payload

El payload por defecto (payload/payload.c) es un programa de solo validación que escribe un archivo marcador. Para construir un payload personalizado:

Edita payload/payload.c. El programa se compila contra nolibc (la biblioteca C mínima del kernel) para obtener un binario estático sin dependencias.
Ejecuta make payload para compilar de forma cruzada.
El payload compilado se incrusta en el binario Go mediante //go:embed.

Versiones Afectadas

Kernel Linux: Todas las versiones anteriores al parche de CVE-2026-31431.
Kubernetes: Cualquier versión que use un kernel de nodo sin parchear. 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 una corrupción local del page-cache a un escape completo de contenedor.

Mitigación

Parchea el kernel. Esta es la solución definitiva.
Habilita el aislamiento de capas de imagen. Algunos runtimes admiten snapshots de sistema de archivos por contenedor que evitan la compartición del page-cache.
Usa sistemas de archivos raíz de solo lectura para kube-proxy (no mitiga por completo, pero limita las capacidades del payload).
Restringe la programación de pods para evitar que cargas de trabajo no confiables aterricen en nodos que ejecutan DaemonSets privilegiados con imágenes base compartidas.

Créditos

Descubrimiento y divulgación de CVE-2026-31431: Theori / Xint
Payload C multiplataforma: Tony Gies (LGPL-2.1-or-later OR MIT)
nolibc: Pruebas del kernel Linux (tools/include/nolibc/)

Licencia

El código Go del exploit en este repositorio se proporciona tal cual con fines de investigación.

El payload (payload/payload.c) se deriva de copy-fail-c y tiene doble licencia bajo LGPL-2.1-or-later OR MIT. Consulta LICENSE-LGPL y LICENSE-MIT.

Copy-Fail-CVE-2026-31431-Kubernetes-PoC

Más Populares