{"id":113376,"date":"2024-02-03T13:41:10","date_gmt":"2024-02-03T11:41:10","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/uyazvimost-v-runc-pozvolyayushhaya-vybratsya-iz-kontejnerov-docker-i-kubernetes"},"modified":"2024-02-03T13:41:10","modified_gmt":"2024-02-03T11:41:10","slug":"uyazvimost-v-runc-pozvolyayushhaya-vybratsya-iz-kontejnerov-docker-i-kubernetes","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/novosti-interneta\/uyazvimost-v-runc-pozvolyayushhaya-vybratsya-iz-kontejnerov-docker-i-kubernetes","title":{"rendered":"Vulnerabilit\u00e0 in runc che consente di uscire dai container Docker e Kubernetes","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Nel toolbox per il lancio di container isolati runc, utilizzato in Docker e Kubernetes, \u00e8 stata trovata una vulnerabilit\u00e0 CVE-2024-21626 che consente l'accesso al file system dell'ambiente host da un container isolato. Durante un attacco, un aggressore pu\u00f2 sovrascrivere alcuni file eseguibili nell'ambiente host, riuscendo cos\u00ec a eseguire il proprio codice al di fuori del container. Nel runtime crun e youki, che utilizzano runc, cos\u00ec come in LXC, il problema non si manifesta. La vulnerabilit\u00e0 \u00e8 stata risolta nella versione runc 1.1.12. <\/p>\n

Nel caso si utilizzino toolbox Docker o Kubernetes, l'attacco pu\u00f2 essere effettuato preparando un'immagine del container appositamente formattata, dopo che \u00e8 stata installata e avviata, da cui \u00e8 possibile accedere a un file system esterno. Con Docker, \u00e8 possibile sfruttarlo tramite un Dockerfile specificamente formattato. La vulnerabilit\u00e0 pu\u00f2 essere sfruttata anche se si avviano processi all'interno del container con il comando «runc exec» legando la directory di lavoro allo spazio dei nomi dell'ambiente host. <\/p>\n

La vulnerabilit\u00e0 \u00e8 causata da una perdita di file descriptor interni. Prima di eseguire il codice all'interno del container, runc chiude tutti i file descriptor utilizzando il flag O_CLOEXEC. Tuttavia, dopo l'esecuzione della funzione setcwd(), rimane un file descriptor aperto che punta alla directory di lavoro e continua a essere accessibile dopo l'avvio del container. Sono stati proposti diversi scenari base di attacco all'ambiente host utilizzando il file descriptor residuo. <\/p>\n

Ad esempio, l'attaccante pu\u00f2 specificare nell'immagine del container il parametro process.cwd, puntando a «\/proc\/self\/fd\/7\/», il che porter\u00e0 a legare la directory di lavoro al processo pid1 nel container, che si trova nello spazio di montaggio dell'ambiente host. In questo modo, nell'immagine del container \u00e8 possibile configurare l'avvio di «\/proc\/self\/fd\/7\/..\/..\/..\/bin\/bash» e, attraverso l'esecuzione di uno script shell, sovrascrivere il contenuto di «\/proc\/self\/exe», che punta alla copia host di \/bin\/bash. <\/p>\n

Un altro tipo di attacco consente a un aggressore, bloccato all'interno del container, di accedere alla directory dell'ambiente host, se nel container vengono avviati processi privilegiati tramite il comando «runc exec» con l'opzione «—cwd». L'attaccante pu\u00f2 sostituire il percorso del processo avviato con un link simbolico che punta a «\/proc\/self\/fd\/7\/» e ottenere l'apertura di «\/proc\/$exec_pid\/cwd» per accedere al file system sul lato host. L'attaccante pu\u00f2 anche sovrascrivere file eseguibili sul lato host avviando un file eseguibile dall'ambiente host («\/proc\/self\/fd\/7\/..\/..\/..\/bin\/bash») e successivamente sovrascrivendo il file «\/proc\/$pid\/exe», che punta al file in esecuzione. <\/p>\n

Inoltre, sono state identificate altre cinque vulnerabilit\u00e0 nei componenti della toolbox Docker: <\/p>\n