Due vulnerabilità gravi scoperte nel 2025 nel celebre tool sudo
— CVE-2025-32462 e CVE-2025-32463 — ci obbligano a riflettere su un punto cruciale e spesso trascurato: serve davvero un binario setuid root
per qualcosa che dovrebbe essere solo una scorciatoia da terminale?
Nel giugno 2025, sudo
è stato aggiornato alla versione 1.9.17p1 per correggere due bug:
-h
in modo improprio per ingannare il controllo di policy e ottenere accesso root anche su host non autorizzati.--chroot
, un utente locale poteva iniettare una libreria malevola e ottenere root. Bastava preparare una directory scrivibile in /tmp
con un falso nsswitch.conf
e una libreria finta.Il problema non è tanto il bug in sé. I bug esistono ovunque. Il problema è l’ambiente privilegiato in cui questi bug vivono: sudo
è un binario compilato, setuid root
, che esegue codice in condizioni di massimo privilegio. Se qualcosa va storto, l’attaccante è root.
Ora poniamoci una domanda semplice: e se sudo
fosse solo uno script Bash che richiama su
?
#!/bin/bash
su -c "$@"
Questa implementazione grezza (che andrebbe ovviamente affinata) è già più sicura di qualunque binario sudo
vulnerabile. Perché?
setuid
attivo. Su sistemi Unix-like, se un file è uno script (con shebang), il kernel ignora il bit setuid
. Quindi lo script non può mai eseguire con privilegi elevati “di nascosto”.su
, che a sua volta richiede la password di root o del target./tmp
. Niente interpreti C. Solo shell.In pratica, l’ambiente Bash è molto più difficile da sfruttare, non perché sia invulnerabile, ma perché non ti concede privilegi arbitrari in caso di bug.
sudo
?Sudo è nato per semplificare l’esecuzione di comandi con privilegi elevati senza dover condividere la password di root. Ma oggi, il tool è diventato una macchina mostruosa da 100k+ linee di C, con supporto a policy, host-specific rules, plugin dinamici e mille altre cose che nessun sysadmin normale usa.
Sudo è nato come scorciatoia, ma oggi è:
E tutto questo con un flag setuid
che, in caso di bug, ti regala root.
su
, e zero sorpreseChiariamo: non tutto può essere uno script Bash. Ma strumenti che hanno come unico scopo quello di “eseguire un comando con privilegi elevati” non hanno bisogno di diventare dei mini-kernel.
Un piccolo wrapper Bash con su
, magari con logging e controllo dei gruppi utente, è:
setuid
.In un’epoca in cui ogni nuova riga di C potenzialmente introduce una CVE, tornare a Bash non è un passo indietro. È buonsenso.
Se sudo
fosse stato scritto in Bash, oggi non staremmo parlando di privilege escalation via chroot o di librerie caricate da /tmp
.
Siamo circondati da tool che hanno dimenticato la loro missione originale. Ricordiamola noi, invece: sudo non è altro che una scorciatoia da terminale. E come ogni scorciatoia, più è semplice, più è sicura.