Sudo d’estate: vulnerabilità critica nelle versioni sudo Linux

Con il caldo che avanza, non è solo il nostro corpo a “sudo…rare”. Anche i sistemi Linux, quest’estate, si trovano a fronteggiare una sudata imprevista: una vulnerabilità critica scoperta in sudo, il celebre comando che da decenni permette agli utenti di eseguire operazioni come amministratori senza dover accedere direttamente come root. Ma questa volta, un bug nella gestione di --chroot rischia di trasformare un semplice comando di sistema in una porta spalancata per attaccanti locali.

Un’estate calda per la sicurezza Linux

Il 1 luglio 2025 è stato pubblicato un advisory ufficiale che descrive una vulnerabilità classificata come CVE-2025-32463, con un punteggio CVSS di 9.3, che la rende una delle falle più gravi degli ultimi anni legate a sudo. Il bug interessa le versioni di sudo dalla 1.9.14 fino alla 1.9.17 inclusa, escludendo soltanto la 1.9.17p1, che contiene la correzione.

Cos’è sudo ?

sudo è uno dei comandi fondamentali dell’amministrazione di sistemi Unix e Linux. Il suo nome deriva da “superuser do“, cioè “esegui come superutente”. In pratica, consente a un utente normale di eseguire comandi con i privilegi di root (o di un altro utente specificato), ma senza dover effettuare un login come root. Questo meccanismo è fondamentale per la sicurezza: consente di controllare, loggare e limitare l’accesso ai privilegi amministrativi.

Attraverso il file di configurazione /etc/sudoers, è possibile definire con estrema precisione quali utenti possono eseguire quali comandi, su quali host, e con quali opzioni. In un contesto aziendale o multiutente, sudo permette di mantenere traccia delle attività privilegiate e ridurre i rischi legati all’uso del superutente. È quindi un pilastro della gestione sicura di sistemi Linux, ma proprio per il suo potere, quando si scopre una vulnerabilità in sudo, le conseguenze possono essere molto serie.

Il problema in breve

Il problema nasce dall’uso dell’opzione --chroot (equivalente a -R) che consente di eseguire comandi all’interno di un ambiente chrootato, utile ad esempio per operazioni di manutenzione su sistemi non avviati normalmente. Tuttavia, in queste versioni affette, sudo non gestisce correttamente la separazione tra l’ambiente chroot e il file system reale. In determinate condizioni, un utente non privilegiato può:

• creare una directory chroot controllata;
• includere in essa file come /etc/nsswitch.conf manipolati;
• sfruttare il caricamento dinamico delle librerie configurate in nsswitch.conf;
• ottenere esecuzione di codice con privilegi root.

Non si tratta di un attacco remoto, ma è comunque devastante, in quanto basta un utente locale senza privilegi root che abbia accesso al comando sudo, anche solo per un sottoinsieme di comandi.

Come funziona l’exploit (a grandi linee)

Un attaccante può costruire un ambiente chroot fittizio con:

1. Una copia di /bin/sh o altro eseguibile indispensabile per avviare una shell di base nel contesto isolato;
2. Una versione artefatta di /etc/nsswitch.conf, contenente riferimenti a moduli personalizzati per la risoluzione dei nomi, ad esempio:

   passwd: mymaliciousmodule
   group: mymaliciousmodule
   shadow: mymaliciousmodule

   Questo forzerà sudo a caricare una libreria .so corrispondente a libnss_mymaliciousmodule.so.2;

3. Una libreria .so malevola, scritta e compilata ad hoc, posizionata nella struttura simulata di /lib, /usr/lib o simili all’interno del chroot, così da essere individuata dal linker dinamico;
4. Una struttura minima coerente nel chroot, che permetta al comando invocato (es. /bin/sh) di avviarsi e generare errori il meno possibile (inclusi device speciali fittizi, /proc, eventuali symlink);
5. Infine, l’esecuzione del comando:

   sudo -R /tmp/fakechroot /bin/sh

A questo punto, sudo, rispettando il parametro --chroot, cambia root nel percorso specificato (/tmp/fakechroot) ed esegue il comando richiesto. Nel farlo, tenta di risolvere le configurazioni nsswitch, caricando moduli dinamici con privilegi elevati. Poiché la libreria .so è posizionata da un attaccante e include codice arbitrario, quest’ultimo viene eseguito come root all’interno del processo sudo.

L’aspetto più critico è che questo avviene senza sfruttare vulnerabilità classiche come buffer overflow o corruzione della memoria: si tratta di un abuso logico, basato sulla fiducia che sudo ripone nell’infrastruttura chroot. Per questo motivo, l’attacco è relativamente semplice da realizzare per chiunque abbia accesso locale e anche solo un’abilitazione parziale a sudo.

Quali distribuzioni sono vulnerabili?

Le distribuzioni vulnerabili sono tutte quelle che hanno adottato sudo in versione >= 1.9.14 e <= 1.9.17, quindi in particolare:

• AlmaLinux 8, AlmaLinux 9 e AlmaLinux 10
• Rocky Linux 8/9;
• RHEL 8/9, se aggiornato con sudo recente;
• Ubuntu (soprattutto versioni 22.04 LTS aggiornate);
• Debian testing/sid, se ha ricevuto la versione 1.9.14+;
• macOS Sequoia e versioni recenti che integrano sudo aggiornato;
• SUSE Linux Enterprise e openSUSE recenti.

CentOS 7: fuori pericolo (per una volta)

Strano ma vero: CentOS 7, ormai dichiarata morta (EOL) da giugno 2024, si salva. La versione di sudo inclusa nei repository ufficiali di CentOS 7 è la 1.8.23, rilasciata intorno al 2017 e rimasta tale fino alla fine del supporto. Questa versione, pur essendo molto datata, non implementa ancora l’opzione --chroot (-R) introdotta nelle versioni successive della serie 1.9, e proprio per questo non è affetta dalla vulnerabilità CVE-2025-32463.

Dal punto di vista tecnico, il codice sorgente di sudo 1.8.23 non supporta il parametro --chroot, né dispone delle routine che effettuano il cambio di root temporaneo e il caricamento del file /etc/nsswitch.conf all’interno dell’ambiente chroot. Ciò significa che anche se un attaccante tentasse di creare un ambiente manipolato, sudo non sarebbe in grado di utilizzarlo secondo la logica vulnerabile delle versioni 1.9.x.

Tuttavia, è importante sottolineare che questo “salvataggio” è frutto del caso e non di un vantaggio di sicurezza intrinseco. CentOS 7 è una distribuzione completamente fuori supporto: i suoi pacchetti contengono numerose vulnerabilità note, non patchate, in componenti critici come il kernel, glibc, OpenSSL, systemd, OpenSSH e molti altri. Continuare a utilizzare CentOS 7 in ambienti di produzione rappresenta un rischio significativo.

In altre parole, per questa vulnerabilità specifica gli utenti CentOS 7 possono tirare un sospiro di sollievo, ma non devono considerarsi al sicuro nel complesso. È fortemente consigliato pianificare una migrazione verso una distribuzione supportata come AlmaLinux 8/9 o Rocky Linux 8/9, approfittando degli strumenti di transizione messi a disposizione dalla comunità, come ELevate di AlmaLinux.

Come verificare se sei vulnerabile ?

Esegui semplicemente:

sudo --version

Se ottieni un output come:

Sudo version 1.9.17

sei vulnerabile.

Se invece hai:

Sudo version 1.9.17p1

sei già al sicuro (versione corretta).

Se hai una versione più vecchia della 1.9.14 (es. 1.8.23 su CentOS 7), non sei vulnerabile alla CVE-2025-32463.

Mitigazione immediata

Se non puoi aggiornare subito, è possibile mitigare i rischi:

1. Non permettere l’accesso a sudo a utenti non fidati

• Rimuovi utenti da /etc/sudoers o da gruppi come wheel o sudo.
• Usa sudoers per concedere accesso solo a comandi specifici, non ALL.

2. Evita l’uso di --chroot nei tuoi script

Verifica se esistono script o cronjob che contengono:

sudo -R

o

sudo --chroot

Se non usi quella funzionalità, sei già più protetto.

3. Controlla i log

Cerca eventuali utilizzi sospetti di --chroot:

grep 'sudo' /var/log/secure | grep '\-\-chroot'

o

journalctl | grep 'sudo.*--chroot'

4. Ricompilare sudo in versione corretta

In alternativa, se il tuo sistema non dispone ancora della versione corretta di sudo (1.9.17p1 o superiore) e non vuoi o non puoi attendere l’aggiornamento ufficiale tramite il gestore pacchetti, puoi scaricare i sorgenti dal sito ufficiale e procedere alla compilazione manuale.

Ecco i passaggi essenziali:

wget https://www.sudo.ws/dist/sudo-1.9.17p1.tar.gz
tar xzf sudo-1.9.17p1.tar.gz
cd sudo-1.9.17p1
./configure --prefix=/usr/local
make
make install

Questo installerà sudo nella directory /usr/local/bin/sudo, lasciando intatta la versione di sistema in /usr/bin/sudo. È consigliabile aggiornare anche il PATH o creare un link simbolico se vuoi sostituire la versione predefinita.

Se desideri integrare sudo compilato con PAM, logging o plugin avanzati, puoi personalizzare il ./configure con opzioni come:

./configure --prefix=/usr/local --with-pam --with-env-editor --with-logging=syslog

Puoi anche validare l’installazione con:

/usr/local/bin/sudo --version

⚠️ Attenzione: la compilazione manuale di sudo su sistemi di produzione deve essere eseguita con estrema cautela. È opportuno:

• testare prima su ambienti di staging o laboratorio;
• effettuare un backup completo del sistema o almeno di /etc/sudoers;
• evitare di disinstallare la versione di sistema senza verificare che quella compilata funzioni correttamente.

Infine, ricordati di aggiornare le policy sudoers se usi percorsi personalizzati per il binario sudo (es. /usr/local/bin/sudo).

Un futuro senza --chroot?

I maintainer di sudo hanno già annunciato che l’opzione --chroot verrà rimossa nelle prossime versioni del software. Questa decisione deriva dal fatto che, nonostante la sua apparente utilità in scenari di recovery o manutenzione, l’opzione si è dimostrata eccessivamente complessa da gestire in sicurezza. Il bug recentemente scoperto lo conferma: la combinazione tra l’ambiente chroot e la risoluzione dinamica di configurazioni e librerie può introdurre vettori di attacco difficilmente mitigabili.

Il meccanismo --chroot richiede che sudo si comporti correttamente anche in ambienti artificiali e potenzialmente incompleti, il che complica enormemente la logica del codice e aumenta la superficie d’attacco. Inoltre, molte distribuzioni e ambienti reali fanno un uso limitato di questa opzione, rendendola un target secondario in termini di feature ma primario per i rischi.

Per chi ha necessità di eseguire comandi all’interno di ambienti isolati o di tipo chroot, è raccomandato adottare strumenti moderni e nativamente più sicuri come:

• systemd-nspawn: per avviare contenitori leggeri Linux in ambienti con systemd, con isolamento avanzato e logging integrato;
• chroot gestito manualmente: se strettamente necessario, ma solo in ambienti controllati e con fs minimali ben configurati;
• container Docker o Podman: per l’esecuzione di processi in ambienti isolati, con maggiore controllo, portabilità e strumenti di sicurezza consolidati.

Il futuro di sudo sarà quindi più snello, focalizzato sulle funzionalità core e sulle policy granulari, mentre l’esecuzione in ambienti virtualizzati sarà lasciata a soluzioni pensate appositamente per quel compito. Un approccio condivisibile e, alla luce di quanto accaduto, decisamente opportuno.

Conclusione: rinfreschiamo sudo

In questa torrida estate 2025, anche sudo si è messo a sudare: una vulnerabilità semplice da sfruttare ma potenzialmente devastante ha fatto emergere quanto sia importante mantenere sempre aggiornati i tool di sistema, anche quelli “storici” come sudo. Il bug legato all’opzione --chroot, che ha colpito molte delle distribuzioni più recenti, ha mostrato come anche un software maturo e consolidato possa nascondere insidie se non adeguatamente manutenuto.

E mentre alcuni sistemi più vecchi si salvano per pura coincidenza temporale, il quadro generale rimane allarmante: la fiducia nel software privilegiato non può mai essere cieca. Gli ambienti di produzione devono essere costantemente monitorati, aggiornati e verificati. Nessun componente va dato per scontato, soprattutto se ha il potere di trasformare un utente normale in root.

Il consiglio è semplice ma strategico: verifica la versione di sudo, aggiorna se necessario, limita l’accesso agli utenti e monitora i log. Aggiungi controlli nei tuoi audit, rimuovi il superfluo nelle policy sudoers e considera anche l’adozione di strumenti più granulari per il controllo degli accessi privilegiati.

E magari, nel dubbio, offri un asciugamano anche ai tuoi server: quest’estate, stanno sudo-rando anche loro. Ma con gli aggiornamenti giusti, almeno eviteranno i colpi di calore da CVE.