Lo strano bug di sudo

Il comando sudo è, in ambito Unix e Linux, da ormai qualche tempo il metodo prediletto dai sistemisti per evitare di condividere password di root o autorizzare specifici utenti all’esecuzione di specifici comandi.

Infatti mentre fino a qualche anno fa era normale richiedere la password di amministratore durante l’installazione di un sistema Linux, oramai lo standard è non richiederla più, permettendo all’utente di creare un coppia utente/password durante l’installazione ed attivando la stessa all’esecuzione di tutto sul sistema tramite il popolare comando.

Normalmente l’esecuzione di un comando tramite sudo richiede l’inserimento della password dell’utente che sta cercando di eseguire il comando come amministratore, tramite la classica dicitura:

Password:

Alcuni utenti (soprattutto i meno avvezzi alla riga di comando) rimangono perplessi quando l’inserimento della password non corrisponde a nessun movimento del cursore sullo schermo. Per questo motivo in sudo è presente un’opzione aggiuntiva: pwfeedback.

Questa opzione, come si può intuire dal nome, permette di avere feedback durante l’inserimento della password, normalmente mostrando un asterisco ad ogni pressione di tasto. Utenti meno perplessi, sysadmin più felici.

Finché non si scopre un bug proprio in quella funzionalità. A causa di un bug recentemente scoperto infatti, quando pwfeedback è attivo è possibile scatenare un Segmentation Fault e scrivere arbitrariamente su buffer presenti nello stack.

Come è possibile tutto questo? Semplicemente inviando una stringa sufficientemente lunga in input a sudo tramite una pipe. La cosa preoccupante è che non solo è estremamente semplice sfruttare l’anomalia, ma che non si deve neanche essere per forza abilitati all’uso di sudo quando lo si vuole utilizzare, rendendo di fatto il sistema vulnerabile da qualsiasi utente.

I problemi che causano la vulnerabilità sono due: dapprima l’opzione pwfeedback non viene ignorata nonostante non si stia leggendo la password da un terminale (ma la si riceva da un buffer, stdin per l’appunto). Questo fa si che il numero di caratteri da rimpiazzare con l’asterisco sia impostato a 0. Successivamente il codice che si occupa proprio di cancellare la riga di asterischi non fa correttamente il reset della posizione le buffer se c’è un errore di scrittura, e questo fa si che la syscall che si occupa di scrivere (getln() per i curiosi) scriva oltre il buffer stesso.

Ora, fortunatamente questa funzionalità di sudo è disattivata di default, rendendo la maggior parte dei sistemi protetti da questo strano bug, ma alcune distribuzioni di largo uso come ElementaryOS e Linux Mint l’attivano di default. Per sapere se il vostro sistema ha pwfeedback attivo vi basta lanciare il comando sudo -l da un utente abilitato al sudo:

$ sudo -l
Matching Defaults entries for mouser on test-sudo-bug:
    pwfeedback, ...

Se la prima regola riporta pwfeedback e non avete aggiornato sudo recentissimamente, allora siete vulnerabili. Come risolvere? Beh, se possibile ovviamente aggiornate sudo ad una versione superiore alla 1.8.25p1, altrimenti vi basterà disattivare l’opzione pwfeedback nel vostro file sudoers.

Come di consueto è stata aperta una CVE a riguardo ed, i dettagli, li trovate sul post del blog del progetto sudo.

Come sempre: aggiornate, aggiornate, aggiornate.

Utente Linux/Unix da più di 20 anni, cerco sempre di condividere il mio know-how; occasionalmente, litigo con lo sviluppatore di Postfix e risolvo piccoli bug in GNOME. Adoro tutto ciò che può essere automatizzato e reso dinamico, l'HA e l'universo container. Autore dal 2011, provo a condividere quei piccoli tips&tricks che migliorano il lavoro e la giornata.

Tags: ,