# Repository klonen
git clone https://github.com/grabesec/XCP_ng_CVE-2026-43284_tester.git
cd XCP_ng_CVE-2026-43284_tester

# Diagnose ausführen (als Nicht-Root für den stärksten Nachweis)
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] Pre-flight-Umgebungsprüfungen
---------------------------------------------
[*] Unprivilegierte Benutzernamensräume : ERLAUBT
[*] esp4-Blacklist in modprobe.d  : NICHT GEFUNDEN
[*] CVE-2026-43284-Patch im Kernel-RPM : NICHT GEFUNDEN

[Phase 1] Basisstatus des esp4-Moduls
---------------------------------------------
[*] esp4 ist SCHLAFEND – derzeit nicht im Kernel geladen.
    Der Autoload-Mechanismus könnte es bei Bedarf über XFRM nachladen.

[Phase 2] Versuch der esp4-Aktivierung aus unprivilegiertem Namensraum
---------------------------------------------
[*] Erzeuge Kindprozess in isoliertem Benutzer- und Netzwerk-Namensraum
    (unshare -U -n -r) – simuliert einen lokalen Nicht-Root-Angreifer

[*] Kind-Signal    : XFRM SA vom Kernel akzeptiert
[*] esp4-Referenzzähler : 0 (vorher) -> 1 (jetzt)
[*] /proc/modules   : esp4 16384 1 - Live 0xffffffffc0a12000

[Phase 3] Technisches Urteil
=================================================================

  [!!!]  NACHWEIS DER EXPONIERUNG – CVE-2026-43284  [!!!]

  Referenzzähler von esp4 erhöht: 0 -> 1

  Ein unprivilegierter Prozess innerhalb eines Benutzer- und
  Netzwerk-Namensraums hat erfolgreich eine XFRM-Sicherheitsassoziation
  registriert und die esp4-Direktentschlüsselungsengine im Host-Kernel
  aktiviert. Dies ist die Eingangsbedingung für CVE-2026-43284.

  XCP-ng-spezifische Analyse:
    [FEHLER] Kernel 4.19 enthält den verwundbaren Code (seit 4.14)
    [FEHLER] Benutzernamensräume sind offen – esp4-Pfad erreichbar
    [OK]     rxrpc.ko nicht vorhanden – CVE-2026-43500 trifft nicht zu
    [FEHLER] esp4-Pfad allein ist auf dieser Konfiguration ausreichend

[Phase 0] Pre-flight-Umgebungsprüfungen
---------------------------------------------
[+] esp4-Blacklist in /etc/modprobe.d/ gefunden
    Die Modulladungsabschwächung scheint vorhanden zu sein.
...
[Phase 2] Versuch der esp4-Aktivierung aus unprivilegiertem Namensraum
---------------------------------------------
[+] XFRM-Zustandshinzufügen wurde vom Kernel ABGELEHNT.
    Die esp4-Engine wurde aus dem Namensraum nicht aktiviert.

[ERGEBNIS] Der Namensraum-Trick gewährte keinen esp4-Zugriff.

# Nur aktuellen Status prüfen (keine Änderungen)
sudo ./mitigate.sh --check

# Milderung anwenden (bricht ab, wenn IPsec erkannt wird)
sudo ./mitigate.sh

# Milderung entfernen (nach Anwendung des offiziellen Kernel-Patches)
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   # Diagnoseskript – zuerst ausführen
├── mitigate.sh                        # Milderungsskript mit IPsec-Erkennung
├── README.md                          # Diese Datei – Schnellstart und Übersicht
├── TECHNICAL.md                       # Tiefgehende technische Analyse – Angriffskette,
│                                      # warum rxrpc auf XCP-ng nicht benötigt wird,
│                                      # Erklärung der Skriptinterna
├── CHANGELOG.md                       # Versionsgeschichte
└── LICENSE                            # MIT