CVE-2019-5736 – runC container breakout

A major vulnerability related to containers was released on Feb 12th. The vulnerability allows a malicious container that is running as root to break out into the hosting OS and gain administrative privileges.

Adam Iwanuik, one of the researchers who took part in the discovery shares in detail the different paths taken to discover this vulnerability.

The mitigations suggested as part of the research for unpatched systems are:

  1. Use Docker containers with SELinux enabled (–selinux-enabled). This prevents processes inside the container from overwriting the host docker-runc binary.
  2. Use read-only file system on the host, at least for storing the docker-runc binary.
  3. Use a low privileged user inside the container or a new user namespace with uid 0 mapped to that user (then that user should not have write access to runC binary on the host).

The first two suggestions are pretty straightforward but I would like to elaborate on the third one. It’s important to understand that Docker containers run as root by default unless stated otherwise. This does not explicitly mean that the container also has root access to the host OS but it’s the main prerequisite for this vulnerability to work.

To run a quick check whether your host is running any containers as root:


#!/bin/bash

# get all running docker container names
containers=$(docker ps | awk '{if(NR>1) print $NF}')

echo "List of containers running as root"

# loop through all containers
for container in $containers
do
    uid=$(docker inspect --format='{{json .Config.User}}' $container)
    if [ $uid = '"0"' ] ; then
        echo "Container name: $container"
    fi
done

In any case, as a best practice you should prevent your users from running containers as root. This can be enforced by existing controls of the common orchestration\management system. For example, OpenShift prevents users from running containers as root out of the box so your job here is basically done. However, in Kubernetes your can run as root by default but you can easily configure PodSecurityPolicy to prevent this as described here.

In order to fix this issue, you should patch the version of your container runtime. Whether you are just using a container runtime (docker) or some flavor of a container orchestration system (Kubernetes, Mesos, etc…) you should look up the instructions for your specific software version and OS.

How can Guardicore help?

Guardicore provides a network security solution for hybrid cloud environments that spans across multiple compute architectures, containers being one of them. Guardicore Centra is a holistic microsegmentation solution that provides process-level visibility and enforcement of the traffic flows both for containers and VMs. This is extremely important in the case of this CVE, as the attack would originate from the host VM or a different container and not the original container in case of a malicious actor breaking out.

Guardicore can mitigate this risk by controlling which processes can actually communicate between the containers or VMs covered by the system.

Learn more about containers and cloud security

From Guardicore's
Resource Center

Using the Mitre ATT&CK framework, this webinar will dive into the adversarial techniques that precede and follow the deployment of ransomware itself.
After several unwieldy firewall control deployments, the team learned about the Guardicore Centra Security Platform and began internal discussions about the benefits and possibilities of next-generation segmentation.
 

Subscribe To Our Newsletter

No spam, we promise. We’re only going to send you insights on how to reduce risk in your data center and clouds.

See Centra in Action

Reduce your attack surface and prevent lateral movement with fast and simple segmentation that works everywhere.

See Guardicore Centra in Action

Schedule a demo customized to your specific security needs