{"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\/news\/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 toolkit per l'avvio di container isolati runc, utilizzato in Docker e Kubernetes, \u00e8 stata trovata una vulnerabilit\u00e0 CVE-2024-21626 che consente l'accesso al filesystem dell'ambiente host da un container isolato. Durante l'attacco, un malintenzionato pu\u00f2 sovrascrivere alcuni file eseguibili nell'ambiente host e in questo modo ottenere l'esecuzione del proprio codice al di fuori del container. Nella runtime crun e youki, che utilizzano runc, cos\u00ec come in LXC, il problema non si manifesta. La vulnerabilit\u00e0 \u00e8 stata corretta nella versione runc 1.1.12. <\/p>\n

In caso di utilizzo di strumenti come Docker o Kubernetes, un attacco pu\u00f2 essere effettuato preparando un'immagine del contenitore opportunamente configurata, dopo l'installazione e l'avvio della quale \u00e8 possibile accedere a un file system esterno dal contenitore. Utilizzando Docker, \u00e8 possibile sfruttare l'attacco tramite un Dockerfile specificamente configurato. La vulnerabilit\u00e0 pu\u00f2 anche essere sfruttata se al suo interno vengono eseguiti processi tramite il comando «runc exec», legando la directory di lavoro allo spazio dei nomi dell'ambiente host. <\/p>\n

La vulnerabilit\u00e0 \u00e8 causata dalla fuoriuscita di descrittori di file interni. Prima di eseguire il codice all'interno del container in runc, viene eseguita la chiusura di tutti i descrittori di file tramite il flag O_CLOEXEC. Tuttavia, dopo l'esecuzione successiva della funzione setcwd(), rimane aperto un descrittore di file che punta alla directory di lavoro e continua a essere accessibile dopo l'avvio del container. Sono stati proposti diversi scenari di attacco di base all'ambiente host, utilizzando il descrittore di file rimanente. <\/p>\n

Ad esempio, l'attaccante pu\u00f2 specificare nell'immagine del contenitore il parametro process.cwd, che punta a « \/proc\/self\/fd\/7\/ », il che porter\u00e0 il legame della directory di lavoro al processo pid1 nel contenitore, che si trova nello spazio di montaggio dell'ambiente host. In questo modo, nell'immagine del contenitore si pu\u00f2 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 fa riferimento alla copia host di \/bin\/bash. <\/p>\n

Un'altra variante dell'attacco consente a un aggressore, bloccato all'interno di un contenitore, di accedere alla directory dell'ambiente host, se nel contenitore vengono eseguiti processi privilegiati tramite il comando «runc exec» con l'opzione « --cwd». L'attaccante pu\u00f2 modificare il percorso del processo in esecuzione per puntare a un link simbolico che si riferisce a « \/proc\/self\/fd\/7\/ » e ottenere l'apertura di «\/proc\/$exec_pid\/cwd» per accedere al file system sull'host. L'attaccante pu\u00f2 anche sovrascrivere file eseguibili nell'ambiente host, avviando un file dal sistema host (« \/proc\/self\/fd\/7\/..\/..\/..\/bin\/bash») e sovrascrivendo successivamente il file «\/proc\/$pid\/exe», che fa riferimento al file eseguito. <\/p>\n

Inoltre, sono state individuate altre cinque vulnerabilit\u00e0 nei componenti degli strumenti Docker: <\/p>\n