Negli strumenti di gestione dei contenitori Linux isolati Docker vulnerabilità (), che in determinate circostanze consente di accedere all'ambiente host dal contenitore se si ha la possibilità di eseguire le proprie immagini nel sistema o se si ha accesso al contenitore in esecuzione. Il problema si manifesta in tutte le versioni di Docker ed è ancora non risolto (è stata proposta una soluzione, ma non è ancora stata accettata, , che implementa la sospensione del funzionamento del contenitore durante l'esecuzione di operazioni sul FS).
La vulnerabilità consente di estrarre file dal contenitore in una qualsiasi parte del FS del sistema host durante l'esecuzione del comando «docker cp». L'estrazione dei file avviene con i diritti di root, il che consente di leggere o scrivere qualsiasi file nell'ambiente host, sufficiente per ottenere il controllo sul sistema host (ad esempio, è possibile riscrivere /etc/shadow).
L'attacco può essere effettuato solo nel momento in cui l'amministratore esegue il comando «docker cp» per copiare file nel contenitore o da esso. Pertanto, l'attaccante deve in qualche modo convincere l'amministratore di Docker della necessità di eseguire questa operazione e prevedere il percorso utilizzato nella copia. D'altra parte, l'attacco può essere effettuato, ad esempio, quando i servizi cloud forniscono strumenti per copiare file di configurazione nel contenitore, costruiti utilizzando il comando «docker cp».
Il problema è causato da una mancanza nell'implementazione della funzione , che calcola il percorso assoluto nel FS principale sulla base di un percorso relativo che considera la posizione del contenitore. Durante l'esecuzione del comando «docker cp» si verifica un breve , durante il quale il percorso è già stato verificato, ma l'operazione non è ancora stata completata. Poiché la copia avviene nel contesto del FS principale del sistema host, in quel lasso di tempo è possibile sostituire il collegamento con un altro percorso e avviare la copia dei dati in un luogo arbitrario del file system al di fuori del contenitore.
Poiché la finestra temporale di manifestazione dello stato di gara è molto limitata nel Nell'esecuzione di operazioni di copia da un contenitore, è stato possibile effettuare un attacco riuscito in meno dell'1% dei casi durante la sostituzione ciclica del collegamento simbolico nel percorso utilizzato per l'operazione di copia (l'attacco riuscito è stato realizzato dopo circa 10 secondi di tentativi continui di copiare un file utilizzando il comando "docker cp").
Nell'esecuzione dell'operazione di copia in un contenitore si può ottenere un attacco ripetibile per la sovrascrittura di un file nel sistema host in sole poche iterazioni. La possibilità dell'attacco è legata al fatto che, durante la copia nel contenitore, viene applicata la concettualizzazione "chrootarchive", secondo la quale il processo archive.go estrae l'archivio non nel chroot della radice del contenitore, ma nel chroot della directory principale del percorso di destinazione, controllato dall'attaccante, e non interrompe l'esecuzione del contenitore (il chroot è utilizzato come indicatore per sfruttare lo stato di competizione).
Fonte: opennet.ru
