Runc and CVE-2019-5736

Containers OpenShift Security
  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: 

Schermafbeelding

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

Schermafbeelding

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: 

Schermafbeelding

Meer info.

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

Gerelateerde posts

De Invloed van Populaire Media op Cyber Security

In deze video wilde Wander met jullie een discussie op gang brengen over hoe afbeeldingen van Cyber Security in Populaire media een vertekend beeld geven bij het algemene publiek over het vakgebied.

Begrens je Gebruikers tot Containers

Als je een systeem hebt waar gebruikers van een afstand op mogen inloggen kan het handig zijn vanuit security of resource optiek om ze te beperken tot wat ze mogen doen. Hier zijn een aantal traditionele mogelijkheden voor, maar tegenwoordig kun je hun sessies ook beperken tot het draaien in een container. Dit heeft een aantal voordelen ten opzichte van traditionele methodes, zo komen bijvoorbeeld alle sessies uit in dezelfde container, en kan het verkrijgen van extra rechten permanent dichtgezet worden.

CLI Security

Bij het werken op de command (CLI) is het soms iets te makkelijk om vertrouwelijke te lekken. Dit kan zijn via gevoelige informatie op de commandline zelf, die ook nog eens in je history kan worden opgeslagen, of zelfs via het simpelweg bestaan van een proces van een bepaalde gebruiker.