runC is the core run-time container code that lives
underneath several open-source container management
systems like Docker, Kubernetes, ContainerD and CRI-O.
It's widely being used by major cloud hosting and server
However, Aleksa Sarai, a senior software engineer and
runC maintainer at SUSE Linux GmbH, has announced a
security problem with runC that could allow attackers to
escape Linux containers and obtain unauthorized, root-
level access to the host operating system.
Sarai said, "the vulnerability (CVE-2019-5736) allows
a malicious container to (with minimal user interaction)
overwrite the host runC binary and thus gain root-level
code execution on the host. The level of user interaction is
being able to run any command (it doesn't matter if the
command is not attacker-controlled) as root within a
container in either of these contexts: creating a new
container using an attacker-controlled image or attaching
(docker exec) into an existing container which the attacker
had previous write access to."
The full details of the vulnerability have not been publicly
released to allow vendors to come up with patches before
attacks begin in earnest.
There has been some confusion from software vendors as
to whether or not their particular containers are vulnerable
Red Hat's Principal Product Manager of Containers, Scott
McCarty, has said, "This vulnerability is mitigated by
the use of SELinux in targeted enforcing mode, which
prevents this vulnerability from being exploited. The
default for SELinux on Red Hat Enterprise Linux 7 is
targeted enforcing mode and it is rarely disabled in a
But, Sarai notes that, "This vulnerability is *not* blocked by
the default AppArmor policy, nor by the default SELinux
policy on the "moby-engine" package on Fedora (because
container processes appear to be running as
container_runtime_t). However, it *is* blocked through
correct use of user namespaces (where the host root is
not mapped into the container's user namespace). The
"docker" package as well as podman are protected
against this exploit because they run container processes
Debian and Ubuntu have acknowledged that their Linux
distributions are vulnerable to this problem.
Google, Amazon, Docker and Kubernetes have all issued
security patches to deal with the problem.
The researchers that originally found the problem (Adam
Iwaniuk and Borys Popławski) have some ideas on
mitigating an unpatched runC. They advise:
"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
Tim Mackey, technical evangelist at Synopsis, has
reflected on what this vulnerability means to the
He told SecurityNow about his concerns for the future of
container security, saying that "There are a few ways
container malware is most likely to manifest with the most
worrisome being a malicious base image. For example, a
malicious person could replace a legitimate binary in an
image with something malicious, but ideally with
comparable capabilities. Then they need to publish that
image into a registry and convince someone to use it
within their application. Unfortunately, that's still easier
than it should be. Then the legitimate app developer
merges their app with that malicious base image and
you've effectively embedded the malware."
He went on to say, "The next most worrisome is that
during development the normal security rules in production
are relaxed and you could get some escalation of privilege
scenarios that might create container breakout
opportunities and get the malicious code within the org. A
beachhead could then result."
Finally, "Lastly I worry about poisoning of the host. That
could come from any of the above, and might be more
difficult to detect given that containers are effectively
permitted processes on a machine which could launch
— Larry Loeb has written for many of the last century's major "dead tree" computer magazines, having been, among other things, a consulting editor for BYTE magazine and senior editor for the launch of WebWeek.