{"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\/nl\/blog\/news\/uyazvimost-v-runc-pozvolyayushhaya-vybratsya-iz-kontejnerov-docker-i-kubernetes","title":{"rendered":"Kwetsbaarheid in runc, waarmee men kan ontsnappen uit Docker- en Kubernetes-containers","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

In de toolset voor het starten van ge\u00efsoleerde containers runc, gebruikt in Docker en Kubernetes, is een kwetsbaarheid CVE-2024-21626 ontdekt, die toegang tot het bestandssysteem van de hostomgeving vanuit een ge\u00efsoleerde container mogelijk maakt. Tijdens de aanval kan een aanvaller bepaalde uitvoerbare bestanden in de hostomgeving overschrijven en zo hun code buiten de container uitvoeren. In de runtime crun en youki, die runc gebruiken, evenals in LXC, doet het probleem zich niet voor. De kwetsbaarheid is verholpen in de release runc 1.1.12. <\/p>\n

Bij het gebruik van Docker- of Kubernetes-tools kan een aanval worden uitgevoerd door een speciaal geprepareerd containerafbeelding te maken, waarna, na installatie en lancering, vanuit de container kan worden verwezen naar het externe bestandssysteem. Bij het gebruik van Docker is er een mogelijkheid tot exploitatie via een speciaal geconfigureerde Dockerfile. De kwetsbaarheid kan ook ge\u00ebxploiteerd worden wanneer processen in de container worden uitgevoerd met het commando 'runc exec' door de werkdirectory aan de namespace van de hostomgeving te koppelen. <\/p>\n

De kwetsbaarheid wordt veroorzaakt door een lek van interne bestandsdescriptoren. V\u00f3\u00f3r de uitvoering van code binnen de container wordt in runc alle bestandsdescriptoren gesloten met behulp van de flag O_CLOEXEC. Echter, na de latere uitvoering van de functie setcwd() blijft er een open bestandsdescriptor, verwijzend naar de werkdirectory, dat toegankelijk blijft na de lancering van de container. Er zijn verschillende basisaanvallen voorgesteld op de hostomgeving waarbij gebruik wordt gemaakt van de overgebleven bestandsdescriptor. <\/p>\n

Bijvoorbeeld, de aanvaller kan in de containerafbeelding de parameter process.cwd opgeven, wijzend op '\/proc\/self\/fd\/7\/', wat leidt tot de koppeling van de werkdirectory naar het proces pid1 in de container, welke zich bevindt in de mount-ruimte van de hostomgeving. Zo kan in de containerafbeelding de uitvoering van '\/proc\/self\/fd\/7\/..\/..\/..\/..\/bin\/bash' worden ingesteld en door het uitvoeren van een shell-script kan de inhoud van '\/proc\/self\/exe' worden overschreven, die verwijst naar de hostkopie van \/bin\/bash. <\/p>\n

Een andere aanvalsmogelijkheid stelt een aanvaller, beperkt binnen de container, in staat toegang te krijgen tot de directory van de hostomgeving, als in de aangegeven container privileged processen worden uitgevoerd met het commando 'runc exec' met de optie '--cwd'. De aanvaller kan het pad van het uit te voeren proces vervangen door een symbolische link die verwijst naar '\/proc\/self\/fd\/7\/' en zo de toegang tot '\/proc\/$exec_pid\/cwd' verkrijgen voor toegang tot het bestandssysteem aan de hostzijde. De aanvaller kan ook de uitvoerbare bestanden aan de hostomgeving overschrijven door het uitvoeren van het uitvoerbare bestand vanuit de hostomgeving ('\/proc\/self\/fd\/7\/..\/..\/..\/..\/bin\/bash') en vervolgens het bestand '\/proc\/$pid\/exe' te overschrijven, dat verwijst naar het uitgevoerd bestand. <\/p>\n

Bovendien zijn er nog vijf kwetsbaarheden in de Docker-toolkitcomponenten ontdekt: <\/p>\n