Negli strumenti per la gestione di contenitori Linux isolati Docker vulnerabilità (), che in determinate circostanze consente l'accesso all'ambiente host dal contenitore nel caso in cui sia possibile eseguire le proprie immagini nel sistema o se si ha accesso a un contenitore in esecuzione. Il problema si manifesta in tutte le versioni di Docker e rimane irrisolto (è stata proposta una soluzione, ma non è ancora stata accettata, , implementando la sospensione del funzionamento del contenitore durante le operazioni con il file system).
La vulnerabilità consente di estrarre file dal contenitore in qualsiasi parte del file system dell'host eseguendo il 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 sovrascrivere /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. Così, 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'altra parte, un attacco può essere effettuato, ad esempio, quando i servizi cloud forniscono strumenti per copiare file di configurazione nel contenitore, utilizzando il comando «docker cp».
Il problema è causato da una mancanza nella funzione , che calcola il percorso assoluto nel file system principale in base a un percorso relativo che tiene conto della posizione del contenitore. Durante l'esecuzione del comando «docker cp» si verifica un breve , in cui il percorso è già stato controllato, ma l'operazione non è ancora stata eseguita. Poiché la copia avviene nel contesto del file system principale del sistema host, in quel breve lasso di tempo è possibile sostituire il link 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 per manifestare lo stato di gara è molto limitata nel prototipo di exploit Durante l'operazione di copia nel contenitore, è possibile ottenere un attacco ripetibile per sovrascrivere un file nel sistema host in poche iterazioni. La possibilità di attacco è legata al fatto che, durante la copia nel contenitore, viene applicato il concetto di «chrootarchive», secondo il quale il processo archive.go estrae l'archivio non nella radice chroot del contenitore, ma nella radice chroot della directory genitore del percorso obiettivo, sotto il controllo dell'attaccante, senza interrompere l'esecuzione del contenitore (il chroot è utilizzato come indicatore per sfruttare lo stato di gara).
При выполнении операции копирования в контейнер можно добиться повторяемой атаки по перезаписи файла в хост-системе всего в несколько итераций. Возможность атаки связана с тем, что при копировании в контейнер применяется концепция «chrootarchive», в соответствии с которой процесс archive.go извлекает архив не в chroot корня контейнера, а в chroot родительского каталога целевого пути, подконтрольного атакующему и не останавливает при этом выполнение контейнера (chroot используется как признак для эксплуатации состояния гонки).
Fonte: opennet.ru
