HARDCODE.BLOG

Coding, the superpower that nobody wants to have.

15 Jul 2025

Sudo, exploit e privilegio: perché serve più Bash e meno binari

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?

Cos’è successo: due falle, root per tutti

Nel giugno 2025, sudo è stato aggiornato alla versione 1.9.17p1 per correggere due bug:

  • CVE-2025-32462: bastava usare l’opzione -h in modo improprio per ingannare il controllo di policy e ottenere accesso root anche su host non autorizzati.
  • CVE-2025-32463: sfruttando il flag --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.

E se sudo fosse uno script Bash?

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é?

  • Gli script non possono avere il flag 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”.
  • Il controllo dei privilegi è demandato a su, che a sua volta richiede la password di root o del target.
  • Niente librerie caricate dinamicamente da /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.

Ma allora perché esiste 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 è:

  • un interprete di policy
  • un gestore di log
  • un caricatore dinamico
  • un gateway con poteri da root

E tutto questo con un flag setuid che, in caso di bug, ti regala root.

Ritorno alle origini: Bash, su, e zero sorprese

Chiariamo: 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, è:

  • leggibile
  • auditabile
  • facilmente modificabile
  • e soprattutto, non sfruttabile via setuid.

In un’epoca in cui ogni nuova riga di C potenzialmente introduce una CVE, tornare a Bash non è un passo indietro. È buonsenso.

Conclusione

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.

Written by: Francesco Bianco

Leggi anche