Quando anche sudo tradisce. Due bug, un root e una chroot

Non succede spesso che sudo, uno dei comandi più fidati e scrutinati del mondo Unix, finisca sotto i riflettori per una vulnerabilità davvero seria. Stavolta è successo due volte, e una delle due fa davvero male. Due bug scoperti e documentati di recente – CVE-2025-32462 e CVE-2025-32463 – mostrano come, anche dopo più di 12 anni di sviluppo, errori silenziosi possano ancora nascondersi in piena vista.

Il primo, CVE-32462, è quasi romantico per quanto è vecchio: un difetto nell’uso dell’opzione --host che, in determinate configurazioni di sudoers, può consentire a un utente locale di eseguire comandi con privilegi su host che non dovrebbe nemmeno poter vedere. Roba da manuale, bassa priorità, ma comunque un richiamo interessante per chi pensa che le configurazioni “da laboratorio” non portino guai.

Il secondo è molto più cattivo. CVE-32463 sfrutta l’opzione -R di sudo, che consente di specificare una directory chroot. L’idea è che tu possa lanciare comandi in un ambiente isolato, ma ecco il problema: in quello chroot, se un attacker locale riesce a preparare una struttura con una libnss malevola e un file /etc/nsswitch.conf, sudo – nel tentativo di risolvere i nomi utenti – caricherà quella libreria come se fosse cosa buona e giusta. Risultato? Root immediato. Niente password. Niente privilege escalation lenta. Solo un salto diretto in cima alla montagna. Ed è tutto già sfruttabile con una PoC pubblica, testata e funzionante su diverse distro.

Fa riflettere il fatto che il componente coinvolto – la risoluzione dei nomi utente e la libreria NSS – sia qualcosa di così basilare. La catena chroot + nsswitch.conf + libnss.so.2 non è nuova a problemi simili, ma stavolta è stato sudo stesso a offrire il varco. Se pensiamo che molte distro usano sudo ovunque, anche in script automatizzati e ambienti CI/CD, l’impatto potenziale è molto più ampio di un semplice attacco locale.

La buona notizia? Esiste già la patch. La versione 1.9.17p1 corregge entrambe le vulnerabilità. I maintainer sono stati rapidi, e le distribuzioni principali (Ubuntu, Debian, SUSE, Fedora, macOS inclusi) stanno rilasciando gli aggiornamenti. Però – e qui viene il bello – quanti sysadmin sanno davvero che chroot può diventare una bomba se combinato con NSS? Quanti ambienti legacy stanno ancora usando configurazioni sudo mai revisionate?

Questa storia è un reminder per tutti noi: l’attacco non deve venire da fuori, spesso il vero rischio è chi è già dentro. E soprattutto, non possiamo mai fidarci troppo di nulla, nemmeno del nostro caro, vecchio sudo. Patchate tutto, ma soprattutto – ogni tanto – leggete quel sudoers con occhi nuovi. Potrebbe raccontarvi più di quanto immaginate.

..

ps: Per sapere se il tuo sistema è a rischio per CVE-2025-32463, ti basta controllare due cose:

Versione di sudo installata

Usa il comando:

sudo --version

Se la versione è precedente alla 1.9.17p1, allora il sistema è potenzialmente vulnerabile.

Verifica se sudo -R è usato da qualche script

Anche se raramente usato da utenti normali, alcune distribuzioni o ambienti automatizzati potrebbero utilizzare l’opzione -R (chroot) in script o tool personalizzati. Puoi cercare rapidamente così:

grep -r "sudo -R" /etc /usr /opt /home 2>/dev/null

Se trovi utilizzi sospetti, fai attenzione.

ps2: l’exploit richiede accesso locale e la possibilità di scrivere nel path specificato da -R. Tuttavia, in ambienti multiutente, questa condizione può realizzarsi più facilmente di quanto sembri.