Vulnerability CVE-2019-5736 in runc, allowing to get root privileges on the host
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:
In addition, Aleksa Sarai (i.e., I) discovered that a more sophisticated version of this vulnerability is affected by LXC.
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:
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 with
The CVSSv3 vector (with a rating of 7.2) is:
The issue has been assigned CVE-2019-5736 .
* The problem only applies to the
I attach the appropriate patch that fixes the problem (
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).
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 the
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.
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.
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).
Problem CVE-2019-5736 in trackers of popular Linux distributions:
... and the Kubernetes blog entry (pay attention to the “What should I do?” Section).
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 (i.e., I) discovered that a more sophisticated version of this vulnerability is 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;
- Connect (
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 with
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:
AV:L/AC:H/PR:L/UI:R/S:C/C:N/I:H/A:HThe issue has been assigned CVE-2019-5736 .
* The problem only applies to the
moby-engine package in Fedora. The docker package, like podman , is protected from its operation, since it starts container processes as container_t .Patches
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 the HEAD branch, although the code in libcontainer/nsenter/ changes so rarely that the patch most likely applies 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 the
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).
Source: https://habr.com/ru/post/439964/