RunC Container Breakout Vulnerability

Asif Awan

Last updated on: September 6, 2020

Despite the huge advantages that containers offer in application portability, acceleration of CI/CD pipelines and agility of deployment environments, the biggest concern has always been about isolation. Since all the containers running on a host share the same underlying kernel, any malicious code breaking out of a container can compromise the entire host, and hence all the applications running on the host and potentially in the cluster.

That fear of container isolation failing to hold up turned out to be true yesterday when a vulnerability in runC was announced. runC is the key and most popular software component that most container engines rely on for spinning up containers on a host. The announced vulnerability allows an attacker to break out of the container isolation through a well-crafted attack (technical details of the vulnerability and the exploit are at and compromise the entire host. The vulnerability is particularly nasty because it is not covered by the default AppArmor or SELinux kernel-enforced sandboxing policies.

What can you do to protect your containerized applications?

Even though the exploit is tricky to execute, the exploit code will be released publicly on February 18, so it’s best to protect your container environment by doing the following:

  1. Know which nodes (Docker hosts) you are running the containers, and if you are running a vulnerable version of Docker Engine. If you are a Qualys customer, you can use AssetView to get that information. Docker has released the patch in version 18.09.2.

    AssetView screenshot showing systems vulnerable to the runC vulnerability

  2. Upgrade your Docker hosts to version 18.09.2.
  3. For hosts managed by public cloud service providers, please keep a close watch on how they are addressing the issue.
    GCP –
    AWS –
  4. Qualys is working on releasing the following detections (QIDs), and more vendor-specific QIDs will be launched in the coming days.

    237121 : Red Hat Update for docker (RHSA-2019:0304)
    237120 : Red Hat Update for runc (RHSA-2019:0303)
    351500 : Amazon Linux Security Advisory for docker: ALAS-2019-1156
    371641 : Runc Container Breakout Vulnerability

    You can get more details at Qualys Threat Protection.

What to do in the future?

It’s good to be concerned about any new technology while it matures, but it’s equally important to harden the application build and deployment workflows in order to prevent the attacker from getting an easy lead into exploiting the deployed containers.

  1. Ensure that only those container images that have gone through the defined compliance checks (related to vulnerabilities, packages, etc.) are deployed in production. As an example, you can use the Qualys Container Security solution to promote only those built images that pass the compliance checks on the build nodes.

    Screenshot: Configure Docker Image Validation Policy

  2. Privileged containers, if compromised, can bring down the entire container cluster. Hence, keep a close watch on all privileged containers running in your environment.

    Container Security screenshot

(Asif Awan is CTO for Container Security at Qualys)

Show Comments (3)


Your email address will not be published. Required fields are marked *

  1. I don’t see anything mentioned in this blog post about Qualys accounting for mitigation when SELinux is in enforcing mode. Red Hat officially notes that this is a mitigation:

    “This vulnerability is mitigated on Red Hat Enterprise Linux 7 if SELinux is in enforcing mode. SELinux in enforcing mode is a pre-requisite for OpenShift Container Platform 3.x”

    Is Qualys accounting for that?

    1. No Derek, Qualys’ vulnerability scanning doesn’t account for the mitigations that could be in place. However, we are working on consolidating the container-related image and infrastructure compliance benchmarking under our container security offering when such filtering of vulnerabilities, against the benchmarking/hardening, will be supported.

  2. What about gVisor? It implements sandbox container runtime that provides isolated guest kernel, it also provides rule based execution providing defense in depth. The result? Breakout attack surface is minimised making attackers impossible to gain access to host kernel