Non sono passati due giorni da quando abbiamo pubblicato l’articolo “Due bug, due core dump, troppa leggerezza: due vulnerabilità gravi in Apport e systemd-coredump” che un’altra coppia di elementi di sistema, stavolta udisks e libblockdev sono pronti a rovinare le tranquille giornate estive dei sysadmin Linux di tutto il mondo.

Anche questa volta è la combinazione letale di configurazioni maldestre e design discutibili a consegnare a potenziali attaccanti una strada comoda comoda per diventare root sulle principali distribuzioni Linux.

Le due nuove vulnerabilità, descritte in questo articolo di Bleeping Computer e identificate come CVE-2025-6018 e CVE-2025-6019, sono l’ennesimo promemoria che nessuna configurazione è davvero sicura se lasciata al caso.

La CVE-2025-6018 riguarda PAM – il Pluggable Authentication Module a cui ancora oggi Linux fa riferimento per la gestione delle autenticazioni – su openSUSE Leap 15 e SUSE Linux Enterprise 15: una configurazione quanto meno opinabile consente a un utente locale di ottenere i privilegi dell’utente allow_active.

Nome innocuo, risultato devastante.

Il motivo risiede nella seconda falla – la più succosa – che si annida nel cuore del sistema di gestione dei dischi: libblockdev in combinazione con il demone udisks. Questo servizio, attivo di default in praticamente tutte le distribuzioni Linux, permette a un utente allow_active di diventare root. Basta sapere dove mettere le mani, e Qualys (sempre loro, sì) lo ha dimostrato con una proof of concept completa e funzionante su Ubuntu, Debian, Fedora e openSUSE.

Come se non bastasse, anche senza sfruttare il bug PAM, ottenere i privilegi di allow_active non è affatto difficile. E da lì il passo verso root è, a quanto pare, una passeggiata.

A parlare chiaro è lo stesso Saeed Abbasi, senior manager della Threat Research Unit di Qualys:

Although it nominally requires ‘allow_active’ privileges, udisks ships by default on almost all Linux distributions, so nearly any system is vulnerable. Techniques to gain ‘allow_active,’ including the PAM issue disclosed here, further negate that barrier. An attacker can chain these vulnerabilities for immediate root compromise with minimal effort.

Anche se sulla carta servirebbero i privilegi allow_active, il servizio udisks è presente di default su quasi tutte le distribuzioni Linux, quindi praticamente qualsiasi sistema è a rischio. E ottenere quei privilegi non è affatto difficile: basti pensare al problema di configurazione PAM descritto qui. Un attaccante può mettere insieme queste vulnerabilità e ottenere i privilegi di root con il minimo sforzo.

Ed è proprio questo aspetto a rendere anche questa vulnerabilità preoccupante: sembra infatti far parte di una tendenza. Ancora una volta infatti, sono componenti presenti in configurazioni standard delle distribuzioni Linux. Quindi nessuno può dirsi veramente al sicuro. E no, non basta usare solo SUSE: l’exploit funziona anche altrove, e il codice è già stato testato con successo.

Fortunatamente il post ufficiale su Openwall contiene oltre ai dettagli tecnici anche i link diretti alle patch che risolvono le problematiche.

In un mondo dove anche i servizi pensati per “gestire dischi” diventano potenziali trampolini per ottenere root, l’unica strategia sensata resta sempre la stessa: monitorare e patchare tutto, subito, e guardare con sospetto ogni servizio che gira in background con privilegi che non dovrebbe avere. Perché no, udisks non è solo “una roba da desktop”. È l’ennesima porta sul retro lasciata socchiusa. E qualcuno l’ha appena spinta.

---

Update 10/07/2025: come sfruttare l’eploit.

La catena di attacco avviene nel seguente modo:

1) Si copia il filesystem contenente i file malevoli dalla macchina dell’attaccante alla macchina vittima e lo si monta su /dev/loop0.

2) Prima di chiedere una “resize”, l’attaccante lancia un loop che blocca lo smontaggio del filesystem, mantenendolo montato in uno stato insicuro, privo delle flag nodev e nosuid (che normalmente impedirebbero l’uso di device e privilegi elevati):

while true; do /tmp/blockdev/bash -c 'sleep 10; ls -l /tmp/blockdev/bash' && break; done 2>/dev/null &

3) Si richiede una “resize” del filesystem XFS montato, utilizzando il demone udisks:

gdbus call --system --dest org.freedesktop.UDisks2 --object-path /org/freedesktop/UDisks2/block_devices/loop0  --method org.freedesktop.UDisks2.Filesystem.Resize 0 '{}'

4) L’attaccante manterrà montato il proprio filesystem (contenente il file bash con setuid) sulla macchina vittima. A causa del blocco del demone però, il filesystem verrà anche montato in una directory temporanea (es. /tmp/blockdev) con il setuid attivo.

5) A questo punto si esegue la shell tramite

/tmp/blockdev/bash -p

6) L’attaccante ottiene una shell con privilegi root, grazie al bit setuid.