DirtyFrag CVE-2026-43284 Validation du PoC et détection auditd

Portée : Validation d'escalade de privilèges locale Linux (LPE) axée sur le chemin XFRM/ESP associé à CVE-2026-43284.

Ce dépôt contient un rapport en anglais et des artefacts de preuve issus d'une validation en laboratoire contrôlé du PoC public DirtyFrag. L'accent n'est pas mis sur la fourniture d'un guide d'exploitation, mais sur la documentation de ce qui était visible dans les journaux d'audit Linux et comment ces événements peuvent être transformés en logique de détection SOC pratique.

Rapport PDF complet :

EN: reports/DirtyFrag_CVE-2026-43284_EN.pdf

PL: reports/DirtyFrag_CVE-2026-43284_PL.pdf

Objectif et portée

Le test a été effectué pour vérifier si un utilisateur local normal pouvait obtenir un shell root dans une VM de laboratoire vulnérable et pour déterminer quels événements peuvent être capturés avec auditd.

CVE-2026-43284 concerne une gestion inappropriée des fragments de pages partagées lors d'opérations ESP/IPsec. Sous certaines conditions, un attaquant local peut influencer les données dans le cache de pages et élever ses privilèges. Ubuntu Security évalue cette vulnérabilité à CVSS 3.1 : 7.8 Élevé.

Références techniques :

• Dépôt du PoC public DirtyFrag : https://github.com/V4bel/dirtyfrag
• Ubuntu Security - CVE-2026-43284 : https://ubuntu.com/security/CVE-2026-43284
• Blog Ubuntu - Correctifs disponibles pour la vulnérabilité Dirty Frag Linux : https://ubuntu.com/blog/dirty-frag-linux-vulnerability-fixes-available

Environnement de test

Référence système complète : evidence/logs/system-info-table.md

Résultat

Avant l'exécution du PoC, le contexte de test était un compte utilisateur normal. Après avoir exécuté ./exp, un shell root a été obtenu et confirmé avec whoami et id.

Collecte de preuves

Après le test, les journaux auditd et les résumés de sortie ont été exportés vers un répertoire de preuves local et copiés dans ce dépôt.

Structure du dépôt

Logique de détection auditd

La détection la plus utile n'est pas un événement unique. Le signal le plus fort est la chaîne complète observée dans une courte fenêtre temporelle :

user namespace -> vmsplice/splice -> ESP/XFRM -> su -> root shell with AUID of a normal user

Clés auditd pertinentes

Chaîne d'événements reconstituée

Exemple de corrélation SIEM

IF
  dirty_frag_unshare by auid>=1000
  AND count(dirty_frag_vmsplice + dirty_frag_splice by same exe or pid) >= 3 within 600s
  AND MAC_IPSEC_EVENT / XFRM activity within 1200s
  AND (dirty_frag_su_exec OR execve with euid=0 and auid>=1000) within 1200s
THEN
  alert = "Possible DirtyFrag CVE-2026-43284 Linux LPE"
  severity = high/critical

Recommandations SOC

• Corriger le noyau et imposer un redémarrage sur le noyau corrigé après les mises à jour.
• Collecter la télémétrie des appels système avec auditd, Falco, des outils basés sur eBPF ou un EDR.
• Ne pas alerter sur un seul événement euid=0 ; cela capture également l'utilisation légitime de sudo.
• Corréler unshare, vmsplice, splice, l'activité XFRM/ESP, su et la création de processus root à partir d'une session utilisateur normale.
• Envisager de restreindre kernel.unprivileged_userns_clone lorsque la compatibilité des applications le permet.
• Examiner si les modules ESP/IPsec sont requis pour une classe d'hôte donnée et restreindre le chargement inutile de modules si approprié.
• Transférer les journaux vers un collecteur distant ou un SIEM ; après une LPE, les journaux locaux peuvent être modifiés par l'attaquant.
• Surveiller la qualité d'auditd : lost doit rester 0 pendant les tests et la surveillance en production.
• Maintenir un playbook de triage LPE Linux couvrant l'isolation de l'hôte, la collecte des journaux d'audit, la vérification du noyau en cours d'exécution et la capture des modules chargés.

Remarques

Le statut auditd collecté a montré lost=2555, ce qui signifie que certains événements d'audit ont pu être perdus. La chaîne clé est toujours visible, mais les tests futurs devraient augmenter le backlog d'audit et confirmer lost=0 avant d'exécuter le PoC.

Le rapport se concentre intentionnellement sur CVE-2026-43284 / XFRM/ESP pour éviter de mélanger le périmètre de détection SOC avec d'autres chemins liés à DirtyFrag.