Nel Toolkit per la gestione dei contenitori Docker Linux isolati vulnerabilità (), che, in determinate circostanze, ti consente di accedere all'ambiente host da un contenitore se hai la possibilità di avviare le tue immagini sul sistema o con accesso a un contenitore in esecuzione. Il problema appare in tutte le versioni di Docker e rimane irrisolto (proposto, ma non ancora accettato, , che attua la sospensione del contenitore durante l'esecuzione delle operazioni con le FS).
La vulnerabilità consente l'estrazione di file da un contenitore in una parte arbitraria del file system del sistema host durante l'esecuzione del comando "docker cp". L'estrazione dei file viene eseguita con i diritti di root, il che rende possibile leggere o scrivere qualsiasi file nell'ambiente host, il che è sufficiente per ottenere il controllo del sistema host (ad esempio, è possibile sovrascrivere /etc/shadow).
L'attacco può essere effettuato solo quando l'amministratore esegue il comando “docker cp” per copiare file da o verso il contenitore. Pertanto, l'aggressore deve in qualche modo convincere l'amministratore Docker della necessità di eseguire questa operazione e prevedere il percorso utilizzato durante la copia. D’altro canto, un attacco può essere effettuato, ad esempio, quando i servizi cloud forniscono strumenti per copiare i file di configurazione in un contenitore, creato utilizzando il comando “docker cp”.
Il problema è causato da un difetto nell'applicazione della funzione , che calcola il percorso assoluto nel file system principale in base al percorso relativo, tenendo conto del posizionamento del contenitore. Durante l'esecuzione del comando "docker cp", viene visualizzato un messaggio a breve termine , in cui il percorso è già stato verificato, ma l'operazione non è stata ancora eseguita. Poiché la copia viene eseguita nel contesto del file system principale del sistema host, entro un periodo di tempo specificato, è possibile riuscire a sostituire il collegamento con un altro percorso e avviare la copia dei dati in una posizione arbitraria nel file system al di fuori del contenitore.
Poiché la finestra temporale in cui si verifica una condizione di competizione è altamente limitata in un ambiente preparato Effettuando operazioni di copia da un contenitore, è stato possibile portare a termine un attacco riuscito in meno dell'1% dei casi sostituendo ciclicamente un collegamento simbolico nel percorso utilizzato nell'operazione di copia (l'attacco riuscito è stato effettuato dopo circa 10 secondi di tentativi per copiare continuamente il file in loop con il comando “docker cp”).
Eseguendo un'operazione di copia in un contenitore, è possibile ottenere un attacco ripetibile di sovrascrittura dei file sul sistema host in poche iterazioni. La possibilità di attacco è dovuta al fatto che durante la copia in un contenitore viene utilizzato il concetto di "chrootarchive", secondo il quale il processo archive.go estrae l'archivio non nel chroot della root del contenitore, ma nel chroot del directory padre del percorso di destinazione, controllata dall'attaccante, e non interrompe l'esecuzione del contenitore (chroot viene utilizzato come segnale per sfruttare le condizioni di competizione).
Fonte: opennet.ru
