Qualys scopre Baron Samedit: ne parliamo con Mehul Revankar

Qualys scopre Baron Samedit: ne parliamo con Mehul Revankar

Baron Samedit è forse il più grave bug che coinvolge la sicurezza di sudo, programma usato negli ambienti UNIX-like. Ne abbiamo parlato con Qualys, che ha scoperto la vulnerabilità

di pubblicata il , alle 12:21 nel canale Security
QualysLinuxApple
 

Lo scorso mese i ricercatori di Qualys hanno scoperto Baron Samedit, una vulnerabilità nel codice di sudo, componente fondamentale dei sistemi UNIX-like come Linux, FreeBSD e macOS. Tale vulnerabilità rappresenta una minaccia notevole perché permette a un attaccante di prendere il controllo completo del sistema. Ne abbiamo parlato con Mehul Revankar, vice presidente in Qualys del product management and engineering.

Baron Samedit: il punto di vista di Qualys

XKCD: sudo make me a sandwich

Il comano "sudo" sta per "super user do" ed è impiegato sui sistemi UNIX-like per eseguire comandi con privilegi elevati che possono, quindi, andare ad apportare modifiche al sistema. Ad esempio, per installare programmi o modificare configurazioni del sistema operativo è necessario utilizzare sudo (od operare direttamente come utente root, ma è meno consigliabile). La vignetta di XKCD qui sopra fornisce una spiegazione piuttosto immediata di quale sia l'effetto pratico dell'uso del comando e questo è, in effetti, quanto accade spesso quando ci si scorda di inserire "sudo" davanti al comando desiderato.

Avevamo già parlato di Baron Samedit nel contesto di macOS, ma tali considerazioni si applicano anche a Linux, *BSD, Solaris e gli altri sistemi che ne fanno uso. Il rischio concreto di tale vulnerabilità era quello di permettere l'accesso incontrollato al sistema da parte di malintenzionati, per quanto il meccanismo per sfruttare la falla fosse piuttosto complesso.

Mehul Revankar

Edge9: Qualys ha scoperto baron Samedit, che appare come un problema piuttosto grande per i moltissimi sistemi UNIX-like al mondo. Quanto è seria questa minaccia?

Revankar: Baron Samedit (CVE-2021-3156) è forse la vulnerabilità più significativa riportata per sudo nella memoria recente. La vulnerabilità consente a qualunque utente su un sistema Linux con sudo installato di ottenere i privilegi di root. L'utente potrebbe essere anche uno con pochi privilegi come "nobody" o "www-data". La serietà di questa vulnerabilità è ora accresciuta ulteriormente dagli exploit disponibili pubblicamente.

Edge9: immaginiamo che distribuire le patch nell'ecosistema centralizzato di un produttore di software come Microsoft sia più facile che dover operare nell'ecosistema frammentato di Linux. È effettivamente così? Quanta complessità e difficoltà aggiunge la natura frammentaria del mondo Linux alla distribuzione delle patch?

Revankar: Tutti i sistemi operativi Linux più noti hanno sistemi standard di gestione dei pacchetti e della distribuzione del software incorporati (ad esempio yum, apt-get, ecc). Quel che ne consegue è che aggiornare le versioni vulnerabili [dei pacchetti] alle versioni con le patch è banale su questi sistemi. Diventa in effetti più difficile con sistemi operativi su base Linux che non sono mainstream o se il sistema viene fornito con un dispositivo IoT, perché in quel caso potrebbe non essere mai aggiornato.

Edge9: non sembra essere un fatto così comune nel mondo open source che falle come quella che ha trovato Qualys in sudo riescano a sfuggire per undici anni come in questo caso, ma è effettivamente così? 

Revankar: Baron Samedit era una vulnerabilità complessa da sfruttare. Richiedeva in effetti di concatenare due vulnerabilità per essere sfruttata con successo. Usare le vulnerabilità indipendentemente non sarebbe di grande utilità. Questa è una delle ragioni per cui ci sono voluti più di 10 anni a scoprire Baron Samedit.

Edge 9: Applicare le patch ai sistemi è un processo che può richiedere molto tempo. Qual è la situazione al riguardo e come possono le aziende migliorare i propri tempi di reazione alle patch di sicurezza?

Revankar: È effettivamente un processo lungo, e per buoni motivi. Le squadre dell'IT non vogliono inserire elementi di instabilità nei propri ambienti applicando patch non testate. Ma, così come avviene con qualunque altra vulnerabilità, le squadre dell'IT devono fare un'analisi dell'impatto [delle patch] prima di applicarle. In questo caso, tuttavia, il rischio derivante dalla mancata applicazione della patch ha un peso ben superiore a qualunque altro fattore che potremmo prendere in considerazione. Le aziende possono migliorare la reattività a situazioni come questa investendo in strumenti di automazione che applichino le patch, rompendo i silo tra l'IT e i team di sicurezza.

0 Commenti
Gli autori dei commenti, e non la redazione, sono responsabili dei contenuti da loro inseriti - info

Devi effettuare il login per poter commentare
Se non sei ancora registrato, puoi farlo attraverso questo form.
Se sei già registrato e loggato nel sito, puoi inserire il tuo commento.
Si tenga presente quanto letto nel regolamento, nel rispetto del "quieto vivere".

La discussione è consultabile anche qui, sul forum.
 
^