# Cloner le dépôt
git clone https://github.com/grabesec/XCP_ng_CVE-2026-43284_tester.git
cd XCP_ng_CVE-2026-43284_tester

# Exécuter le diagnostic (en tant que non-root pour la preuve la plus solide)
python3 XCP_ng_CVE_2026_43284_tester.py

=================================================================
  XCP-ng Dirty Frag Diagnostic -- CVE-2026-43284
  xfrm-ESP Page-Cache Write / Local Privilege Escalation
=================================================================
  Kernel  : 4.19.0+1
  Host    : xcpng-prod-01
  PID     : 52306  |  UID: 1000
=================================================================

[Phase 0] Vérifications préliminaires de l'environnement
---------------------------------------------
[*] Espaces de noms utilisateur non privilégiés : AUTORISÉS
[*] Liste noire esp4 dans modprobe.d          : NON TROUVÉE
[*] Correctif CVE-2026-43284 dans le RPM du noyau : NON TROUVÉ

[Phase 1] État de base du module esp4
---------------------------------------------
[*] esp4 est ENDORMI — actuellement non chargé dans le noyau.
    Le mécanisme de chargement automatique peut le récupérer à la demande via XFRM.

[Phase 2] Tentative d'engagement de esp4 depuis un espace de noms non privilégié
---------------------------------------------
[*] Création d'un processus fils dans un espace de noms utilisateur+réseau isolé
    (unshare -U -n -r) -- simulation d'un attaquant local non root

[*] Signal du processus fils : SA XFRM acceptée par le noyau
[*] Référence esp4   : 0 (avant)  ->  1 (maintenant)
[*] /proc/modules    : esp4 16384 1 - Live 0xffffffffc0a12000

[Phase 3] Verdict technique
=================================================================

  [!!!]  PREUVE D'EXPOSITION -- CVE-2026-43284  [!!!]

  Référence esp4 augmentée : 0 -> 1

  Un processus non privilégié à l'intérieur d'un espace de noms
  utilisateur+réseau a enregistré avec succès une association de
  sécurité XFRM et engagé le moteur de déchiffrement sur place
  esp4 dans le noyau hôte. C'est la condition d'accès pour
  CVE-2026-43284.

  Analyse spécifique à XCP-ng :
    [ÉCHEC] Le noyau 4.19 comporte le code vulnérable (depuis la 4.14)
    [ÉCHEC] Les espaces de noms utilisateur sont ouverts -- le chemin esp4 est accessible
    [OK]    rxrpc.ko absent -- CVE-2026-43500 ne s'applique pas
    [ÉCHEC] Le chemin esp4 seul est suffisant sur cette configuration

[Phase 0] Vérifications préliminaires de l'environnement
---------------------------------------------
[+] Liste noire esp4 trouvée dans /etc/modprobe.d/
    L'atténuation par blocage de module semble en place.
...
[Phase 2] Tentative d'engagement de esp4 depuis un espace de noms non privilégié
---------------------------------------------
[+] L'ajout d'état XFRM a été REJETÉ par le noyau.
    Le moteur esp4 n'a pas été engagé depuis l'espace de noms.

[RÉSULTAT] La faille de l'espace de noms n'a PAS accordé l'accès à esp4.

# Vérifier uniquement l'état actuel (aucune modification)
sudo ./mitigate.sh --check

# Appliquer l'atténuation (s'arrête si IPsec est détecté)
sudo ./mitigate.sh

# Supprimer l'atténuation (après application du correctif officiel du noyau)
sudo ./mitigate.sh --undo

echo 'install esp4 /bin/false' > /etc/modprobe.d/dirtyfrag-cve-2026-43284.conf
rmmod esp4 2>/dev/null || true
echo 3 > /proc/sys/vm/drop_caches

XCP_ng_CVE-2026-43284_tester/
├── XCP_ng_CVE_2026_43284_tester.py   # Script de diagnostic — exécutez-le en premier
├── mitigate.sh                        # Script d'atténuation avec détection IPsec
├── README.md                          # Ce fichier — démarrage rapide et aperçu
├── TECHNICAL.md                       # Analyse technique approfondie — chaîne d'attaque,
│                                      # pourquoi rxrpc n'est pas nécessaire sur XCP-ng,
│                                      # explication du fonctionnement interne du script
├── CHANGELOG.md                       # Historique des versions
└── LICENSE                            # MIT