Dirty Frag (CVE-2026-43284) — Preuve de concept d'évasion de conteneur Kubernetes

Une preuve de concept démontrant comment un Pod Kubernetes par défaut, non privilégié peut atteindre une exécution de code au niveau du nœud sur Amazon EKS en exploitant la vulnérabilité de corruption du cache de pages du noyau Linux Dirty Frag via des couches d'images conteneur partagées.

La primitive d'attaque principale est la suivante : tout DaemonSet privilégié partageant des couches d'images avec un conteneur contrôlé par l'attaquant peut être transformé en vecteur d'évasion de conteneur. Cette preuve de concept utilise kube-proxy comme exemple concret, mais la technique se généralise à toute charge de travail privilégiée du cluster.

Validé sur Amazon EKS (noyau 6.12.80) — un pod non privilégié écrit [*] success dans le système de fichiers de l'hôte via le DaemonSet privilégié kube-proxy :

Avertissement : Ce dépôt est publié à des fins éducatives et défensives uniquement. Utilisez-le exclusivement sur des systèmes que vous possédez ou pour lesquels vous disposez d'une autorisation explicite de test.

Contexte

Dirty Frag (CVE-2026-43284) est une vulnérabilité de corruption du cache de pages du noyau Linux dans le chemin de réception xfrm/ESP. Dans le chemin affecté, esp_input() peut ignorer skb_cow_data() pour un skb non linéaire sans frag_list, permettant à crypto_authenc_esn_decrypt() de stocker 4 octets de données contrôlées par l'attaquant dans une page du cache de pages atteinte via splice().

Le fichier sur disque n'est pas modifié. Les octets corrompus résident dans le cache de pages du noyau et sont observés par les lecteurs ultérieurs de la même page de fichier en cache.

Pour tous les détails sur la vulnérabilité d'origine, voir V4bel/dirtyfrag.

Principe de l'attaque

L'attaque exploite trois propriétés qui coexistent couramment dans les clusters Kubernetes :

1. Corruption du cache de pages du noyau (CVE-2026-43284) — un processus non privilégié (avec prise en charge des espaces de noms utilisateur) peut écraser les pages en cache en mémoire de tout fichier qu'il peut ouvrir en lecture seule, via la course xfrm/ESP splice.
2. Partage de couches d'images — les runtimes de conteneurs (containerd, CRI-O) utilisent des systèmes de fichiers overlay où des couches d'images identiques correspondent aux mêmes pages du cache de pages entre les conteneurs.
3. DaemonSets privilégiés — de nombreux clusters exécutent des DaemonSets avec des privilèges élevés (privileged: true, hostNetwork: true, capacités étendues, etc.) qui exécutent périodiquement des binaires de leur image.

Lorsque ces conditions sont réunies, un pod non privilégié peut corrompre un binaire dans une couche d'image partagée, et un DaemonSet privilégié sur le même nœud exécutera sans le savoir le binaire corrompu avec ses privilèges élevés — atteignant ainsi une exécution de code complète au niveau du nœud.

La cible de la vulnérabilité n'est PAS limitée à kube-proxy. Tout DaemonSet privilégié (agents de surveillance, plugins CNI, collecteurs de journaux, agents de sécurité, etc.) dont l'image conteneur partage des couches avec une image contrôlée par l'attaquant est une cible viable.

Différence avec Copy Fail

Ce projet s'inspire du modèle d'exploitation Kubernetes documenté dans la preuve de concept Kubernetes Copy Fail, mais utilise une primitive noyau différente.

Propriété	Copy Fail	Dirty Frag
CVE	CVE-2026-31431	CVE-2026-43284
Chemin noyau	AF_ALG + splice()	xfrm/ESP + splice()
Exigence d'espace de noms	Non requise	Requiert des espaces de noms utilisateur
Capacité principale utilisée	Aucune dans le conteneur initial	CAP_NET_ADMIN dans le nouvel espace de noms réseau
Module concerné	algif_aead	esp4
Distinction pratique	Échoue si le vecteur AF_ALG est bloqué	Toujours pertinent lorsque AF_ALG est indisponible mais que ESP/les espaces de noms utilisateur sont activés

Comment cela fonctionne

La chaîne d'attaque comporte trois étapes : corruption du cache de pages, propagation entre conteneurs et exécution privilégiée.

1. Correction du cache de pages via xfrm/ESP

Le binaire de la preuve de concept effectue la séquence suivante depuis un conteneur non privilégié :

1. Entre dans de nouveaux espaces de noms utilisateur et réseau avec unshare(CLONE_NEWUSER | CLONE_NEWNET).
2. Enregistre de nombreuses associations de sécurité xfrm dont les champs de séquence élevés encodent des morceaux de charge utile de 4 octets.
3. Ouvre un binaire cible de la couche d'image partagée en lecture seule.
4. Utilise splice() et une entrée ESP conçue pour déclencher le chemin vulnérable du noyau.
5. Répète la primitive jusqu'à ce que le contenu du cache de pages du binaire cible contienne la charge utile intégrée.

Aucune permission d'écriture sur le fichier cible n'est requise. Le fichier sur disque est inchangé — seule la mémoire du cache de pages est corrompue.

2. Propagation entre conteneurs via les couches partagées

Les runtimes de conteneurs servent les lectures des couches inférieures overlay via le cache de pages du noyau. Si le conteneur de la preuve de concept et kube-proxy partagent le même fichier de couche inférieure, les deux observent les mêmes pages en cache.

L'image EKS de ce dépôt est construite à partir de :

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

Cette base est choisie pour correspondre à la couche de chaîne d'outils espace utilisateur kube-proxy EKS utilisée dans l'environnement validé.

3. Exécution privilégiée par kube-proxy

Lorsque kube-proxy exécute ensuite un binaire de la famille iptables corrigé, le noyau charge les pages en cache corrompues. La charge utile de la preuve de concept monte le périphérique racine de l'hôte et écrit un fichier marqueur dans /root/res.

Le contenu attendu du marqueur est :

[*] success

Diagramme du flux d'attaque