Docker2_red
adv

Docker è tra i più noti sistemi per la gestione di container e virtualizzazione di applicazioni. Vediamo alcuni aspetti di sicurezza.

 

Come tutti i sistemi informatici, anche Docker è passibile di bug che, assieme ad un uso scorretto, lo rendono possibile bersaglio di cyber-attacchi. Tra recenti accadimenti e best-practice riportiamo alcune considerazioni.

Vulnerabilità

Di recente è stata scoperta una falla nel sistema Docker che prende il nome di CVE-2019-5736. Essa consente, con una minima interazione da parte degli utenti, l’esecuzione di comandi come root (utente amministratore) sul sistema host che ospita i container.

La scoperta è stata fatta da due ricercatori, Adam Iwaniuk e Borys Popławski, mentre Aleksa Sarai ha scoperto che il bug colpirebbe anche altri sistemi di gestione container come LCX ma sembra che neanche Apache MESOS sia al sicuro.

L’attacco

La vulnerabilità di cui sopra consente di sovrascrivere i file binari del programma runc dell’host e, quindi, attuare un’exploit, un’escalation di privilegi fino al livello più alto.

runc è un tool di basso-livello che si occupa dell’interazione tra sistema e container.

L’attacco può avvenire usando immagini malevole o container già compromessi e non viene bloccato dalla configurazione di default di sistemi come AppArmor o SELinux in quanto essi vedranno i processi del container funzionare normalmente come container_runtime_t.

Rimedi

Un utilizzo corretto dei namespace può prevenire il problema: non far girare i container con privilegi di root come da configurazione di default, l’utente root del sistema host non sarà, dunque, mappato nello user namespace del container.

Tale precauzione può essere rafforzata modificando appropriatamente le policy dei sistemi di sicurezza precedentemente citati, assicurandosi che i container non siano eseguiti da utente con UID 0 (root), cosa configurabile anche nell’immagine del container stesso.

Il bug è stato risolto, per cui, si consiglia l’aggiornamento di runc alle versioni sicure. Una settimana dopo è stato rilasciato anche il codice per eseguire l’attacco exploit in modo da consentire, specie nei sistemi commerciali, la verifica della sicurezza.

Versioni Docker sicure

Docker ha rilasciato delle versioni bug-free e raccomanda di aggiornare i sistemi. Per la community-edition (quella gratuita, mantenuta dalla community open-source) le versioni sono la 18.09.2 e 18.06.3, mentre per l’enterprise-edition abbiamo le versioni 18.09.2, 18.03.1-ee-6 e 17.06.2-ee-19.

Best Practice

Al di là del bug precedentemente discusso, esistono best practice da rispettare per garantire la sicurezza. Una di queste è l’utilizzo di immagini e container certificati da Docker che aderiscono quindi alle impostazioni per un sistema ottimale, che abbia passato test funzionali e di vulnerabilità. Tali immagini sono indicate come partenza per realizzare i propri container, esse possono essere semplicemente il sistema operativo minimale di base (e.g.: Ubuntu, Alpine, etc.) oppure già corredato di applicazioni come web-server, database, etc.

Socket aperta

Abbiamo visto che l’architettura di Docker è di tipo client-server dove il primo viene usato via cli (command line interface) per inviare i comandi al secondo e per interpretarne le risposte. Client e server comunicano via HTTP attraverso una Unix socket, una connessione interna. In alcune pratiche, spesso legate ad ottenere un supporto dall’esterno, si può decidere di aprire all’esterno questa socket, facendo viaggiare la comunicazione su canale TCP con indirizzo IP e porta (di default si usa la 2375).

Tale operazione va a scapito della sicurezza in quanto, se la connessione non è ben protetta, espone il sistema, sia server che client, a varie tipologie di attacco ma soprattutto alla possibilità che i dati vengano trafugati e/o comandi vengano impartiti ai container.

Una valida alternativa può essere aggiungere un proxy server, come socat, nel mezzo per far interagire solo alcuni sistemi e veicolare il traffico di rete, in maniera consapevole, da una porta esterna.