Runc and CVE-2019-5736
Containers

Runc and CVE-2019-5736

Jan Kappert
Jan Kappert

Kwetsbaarheid in runc gevonden, wat nu?!

Er is een fout gedetecteerd in runc waardoor een schadelijke container toegang op rootniveau op de hostcomputer kan krijgen.  
 
Dit beveiligingslek raakt zowel de docker– als runc-pakketten die beschikbaar zijn op Red Hat Enterprise Linux 7, die worden geleverd via het kanaal Extra’s. OpenShift Container Platform (OCP) 3.x is afhankelijk van deze pakketten, afkomstig van Red Hat Enterprise Linux 7 Extras en wordt ook beïnvloed.

Wat is Runc​?

Heel kort, runc is een low-level tool die het zware werk doet om containers te starten. Andere tools als Docker, Containerd en CRI-O draaien op Runc om zaken als data formatting en serialisatie aan te pakken. Runc is de kern van al deze systemen. Kubernetes zit op zijn beurt weer bovenop deze tools, Kubernetes zelf is niet kwetsbaar.  

Wat houdt de kwetsbaarheid in?

Hoewel volledige details nog steeds zijn voorzien van embargo's om mensen de tijd te geven om te patchen, is de ruwe versie dat wanneer een proces als root (UID 0) in een container wordt uitgevoerd, dat proces een bug in runc kan misbruiken om root privileges te verkrijgen op de onderliggende hosts die de containers uitvoeren . Dit geeft hen vervolgens onbeperkte toegang tot de server en alle andere containers op die server. 

Als het proces in de container vertrouwd is (iets waarvan u weet dat het niet vijandig is) of niet wordt uitgevoerd als UID 0, is het beveiligingslek niet van toepassing. Het kan ook worden voorkomen door SELinux in enforced mode te draaien. RedHat Enterprise Linux, CentOS en Fedora hebben allemaal de juiste SELinux-rechten bij hun pakketten en worden daarom verondersteld niet te worden beïnvloed. De meest voorkomende risicobron is een attacker-controller container images van publieke repositories. 

Wat kan je eraan doen?

Zoals met alle beveiligingsproblemen zijn er meerdere opties om het beveiligingslek te verminderen. Upgrade naar de laatste versie van runc die de oplossing bevat. Of controleer de policies in uw Openshift of Kubernetes omgeving. 

Aangezien de exploit UID 0 binnen de container vereist, is een directe beperking nodig om te zorgen dat al uw containers worden uitgevoerd als een niet-0 gebruiker. Dit is in te stellen in de container image of via uw podspecificatie: 

Ook is het mogelijk dit globaal te regelen via de PodSecurityPolicy:

 

Bovenstaande is niet nodig in OpenShift als er geen aparte policy’s zijn aangemaakt waarin je een user met UID 0 toelaat om iets te laten draaien in een container. 

Binnen OpenShift is het mogelijk om in te zien wie er gebruik mag maken om containers als UID 0 te laten starten met het volgende commando: 

 

Meer info.

Meer informatie kan je vinden op: https://access.redhat.com/security/vulnerabilities/runcescape