Un’eredità eccessiva e pericolosa!

Uno dei punti di forza dei sistemi GNU/Linux è la rigorosa gestione dei permessi per l’esecuzione dei programmi. Una volta, su questi sistemi esistevano sostanzialmente due sole modalità: quella privilegiata e quella non privilegiata. I file eseguibili dei programmi privilegiati avevano un particolare bit tra i loro metadati, chiamato convenzionalmente SUID. Quando un file eseguibile ha questo bit impostato viene eseguito con i permessi dell’utente che ne è proprietario, a prescindere da chi lo abbia lanciato. Se, per esempio, un eseguibile è proprietà dell’utente root ma viene eseguito da un utente comune, verrà comunque avviato con privilegi di root. Questo bit viene impostato come “vero” solo per alcuni particolari software “sicuri” che ne abbiano davvero bisogno, se si impostasse per qualsiasi programma non ci sarebbe più una separazione tra i privilegi degli utenti. Chiaramente, si tratta di un meccanismo un po’ rigido: il bit può essere attivo oppure no, i privilegi sono da utente normale oppure da root, non ci sono mezze misure. Un modo per limitare parzialmente il potere di SUID è rendere proprietario del file non l’utente root ma un altro utente che, tramite i gruppi a cui appartiene, possa avere accesso a un set limitato di file. Per esempio, se si avvia il server web Apache a nome dell’utente www-data, che appartiene al gruppo www-data, si avrà accesso opzione predefinita per mettere in piedi una applicazione server: i container. Ormai è quasi impossibile trovare del software open source che non venga pubblicato con almeno un’immagine docker. I container sono estremamente utili non soltanto perché separano i vari eseguibili, impedendo che un eventuale attacco su un programma possa ripercuotersi su altri software o sul sistema in generale, ma anche perché permettono di avere diverse versioni dello stesso software sul sistema, senza causare conflitti tra le dipendenze. Un container è autonomo: contiene tutte le librerie necessarie per il funzionamento del programma. Se ce ne sono di più sullo stesso sistema, ciascuno di essi contiene tutte le librerie necessarie a se stesso. Naturalmente, questo comporta un importante consumo di spazio: molte librerie e molti eseguibili saranno sempre gli stessi tra tutti i vari container, ed è uno spreco occupare il doppio, il triplo o anche più dello spazio. Ed è per risolvere questo problema che esiste OverlayFS.

Millefoglie

OverlayFS è un meccanismo di memorizzazione dei file pensato per l’union mounting: si tratta di unire virtualmente più cartelle, facendole apparire come una sola. Il vantaggio è che si possono creare più cartelle con versioni differenti dello stesso software, da montare volta per volta a seconda della versione necessaria in un filesystem completo. Immaginiamo di avere bisogno di MySql 5 in un container e MySql 8 in un altro container, ma per il resto dello stesso sistema di base. Il grosso del sistema può risiedere in una cartella, poi basta averne una per MySql 5 e una per MySql 8. In un container verrà montata la cartella della versione 5 sopra il sistema base, e viceversa nell’altro. In questo modo si risparmia lo spazio che verrebbe sprecato mantenendo sul disco due volte i file del sistema base. Naturalmente, è un po’ più complesso di così, si possono di fatto avere più versioni degli stessi file con una sorta di logica incrementale: quando si fanno modifiche a un container vengono memorizzati solo i file cambiati rispetto all’immagine docker di partenza, sempre per risparmiare spazio. La domanda che si ci potrebbe porre è: cosa succede ai permessi di file e cartelle, capabilities incluse, una volta che vengono montati dentro altre cartelle? Si può immaginare che vengano ereditate, ma è chiaro che si tratti di una situazione complessa, con tanti container che montano gli stessi file in modo diverso. Il problema nasce dal fatto che un malintenzionato potrebbe abusare di OverlayFS per fare in modo che il kernel copi dei file eseguibili con capabilities da amministratore da un punto di mount realizzato appositamente a delle cartelle sul filesystem principale. Facendo la copia, un sistema GNU/Linux non patchato manterrebbe la capability sul file, offrendo quindi al malintenzionato un file con capability da amministratore sul filesystem principale. Siccome OverlayFS può essere usato tramite FUSE anche da utenti semplici, senza alcun privilegio, questo significa che il malintenzionato deve solo crearsi un filesystem (lower, nell’esempio) su un proprio sistema e inserire un eseguibile con capability da amministrazione:

setcap cap_sys_admin +eip lower/suid

Poi deve solo copiare quel filesystem sul sistema da attaccare e montarlo (nella cartella upper):

mount -t overlay overlay -o rw,

lowerdir=lower,upperdir

=upper,workdir=workdir mount

A quel punto si può accedere al file eseguibile dal sistema vittima:

touch mount/suid

getcap lower/suid

E si scopre che la capabilities sono rimaste intatte:

lower/suid = cap_dac_override,

cap_sys_admin+eip

Vulnerabilità

Nessuna delle modifiche da parte degli sviluppatori di Ubuntu ha introdotto vulnerabilità di per se, ma nel 2020 era stata scoperta proprio una vulnerabilità in overlayFS che permetteva l’impostazione di attributi speciali ai file. Il fix è stato applicato alla linea originale di overlayFS, ma non alla versione modificata da Ubuntu. Nello specifico, quando si tratta di gestire i permessi di un file la versione originale chiama una funzione di servizio che è stata realizzata appositamente per assicurarsi che non vengano dati più permessi a file che non dovrebbero averli. Invece, la versione di ubuntu utilizza direttamente la chiamata di sistema __vfs_setxattr_noperm. Il problema è proprio che il flusso di Ubuntu non prevede dei controlli, che invece nel Linux “originale” sono stati inseriti, per evitare di trasferire le capabilities da un filesystem all’altro.

Un dettaglio che è importante ricordare è che questa vulnerabilità ha un impatto su OverlayFS in sé, ma non su docker o più in generale sui container. Un sistema che utilizza docker non è di per se stesso vulnerabile, lo è solo per il fatto che ha certamente lo stack di overlayfs e quindi chi accede al sistema host potrebbe montare filesystem OverlayFS. Ma chi ha accesso solo a un container non può comunque uscire e danneggiare il sistema host.

La soluzione

Le patch per l’implementazione di Ubuntu sono state rilasciate a un mese dalla scoperta delle vulnerabilità, e sono disponibili per le release da Ubuntu 20.04 al più recente 23.10. Purtroppo è vulnerabile anche Ubuntu Bionic (18.04) ma, non essendo più supportata, per questa non è disponibile alcuna patch.

Leggi anche: “Utenti Ubuntu sotto attacco“