Vulnerability CVE-2019-5736 in runc, allowing to get root privileges on the host
  • Transfer
Note trans. : Last night, Aleksa Sarai, senior container engineer from SUSE Linux, reported in the mailing list oss-sec about the critical runc / LXC security vulnerability that allows an attacker who has access to an isolated container to get root privileges on the host system. Since the problem has been identified in the reference implementation of the executable environment for containers, runc, it affects numerous container systems including Docker / Moby, Podman , cri-o (and Kubernetes itself). Below are the details in the form of translation of the message engineer in the mailing list.

I am one of the runc maintainers (the underlying container execution environment used in Docker, cri-o, containerd, Kubernetes, etc.). Recently it became known about the vulnerability, which we checked and patched.

Researchers who discovered the vulnerability:

  • Adam Iwaniuk;
  • Borys Popławski.

In addition, Aleksa Sarai (ie, I) discovered that the more sophisticated version of this vulnerability is also affected by LXC.

Short review

Vulnerability allows a malicious container (with minimal user interaction) to rewrite the runc binary binary and thus be able to execute code with root privileges on the host. The degree of user interaction is such that it allows you to run any commands (no matter if the attacker controls the command) with root rights within the container in any of these contexts:

  • Creating a new container from the image controlled by the attacker;
  • Connection ( docker exec) to an existing container that the attacker previously had write access to.

This vulnerability is not blocked by either the AppArmor default policy or the SELinux default policy in Fedora * (because container processes appear to be running from container_runtime_t). However, it is blocked by the correct use of user-defined namespaces (where the root of the host is not the map in the user namespace of the container).

The CVSSv3 vector (with a rating of 7.2) is as follows: CVE-2019-5736 was


assigned to the problem .

* The problem only applies to the package moby-enginein Fedora. The package docker, as well as podman, is protected from its operation, since it starts the processes of the container as container_t.


I attach the appropriate patch that fixes the problem ( 0001-nsenter-clone-proc-self-exe-to-avoid-exposing-host-b.patch). It is based on a branch HEAD, although the code libcontainer/nsenter/changes so rarely that the patch is most likely applicable to almost any old version of the runc codebase you are dealing with.

Please note that the patch that I push to the runc master branch is a modified version of this patch, although they are functionally identical (if you have not patched your files with the attached patch, we recommend using the upstream version).

Minor Exploit Code

Some vendors requested an exploit code to make sure the patches solved the problem. Since the problem is very serious (especially for vendors of public clouds), we decided to provide such a code. The exploit is written by me, is more general than the original code provided by researchers, and works for LXC (does not require strong modifications to be able to apply to other vulnerable executable environments). Details on how to use the exploit code are provided in README.

In accordance with the rules of OpenWall, the exploit code will be publicly announced 7 days after CRD (i.e. February 18, 2019). If you have an executable environment for containers, please make sure that it is not affected by this vulnerability.

Impact on other projects

It should be noted that in the course of further investigation of the problem, I discovered that LXC has a similar vulnerability, and they already push a similar patch of our joint development. LXC is a little harder to exploit, but the problem itself is the same.

Discussion with representatives of systemd-nspawn led to the conclusion that they are not vulnerable (since they have a different method of connecting to the container for LXC and runc).

I was also contacted by representatives of Apache Mesos, who reported that they were also vulnerable (I think that they simply used the exploit code that will be published). It seems very likely that most executable environments for containers are vulnerable if they have not previously taken some very unusual actions to mitigate its potential impact.

Other news

We set up an announcement mailing for future security vulnerabilities: the process for joining it is described here (it is based on the Kubernetes security-announce mailing list). Please join if you distribute any executable environments for containers that depend on runc (or other OCI projects).

PS From the translator

Problem CVE-2019-5736 in trackers of popular Linux distributions:

... and the Kubernetes blog entry (pay attention to the “What should I do?” Section).

Also popular now: