Container Vulnerability: Still a Reality

A security problem with runC that could allow attackers to

escape Linux containers and obtain unauthorized, root- level access to the host operating system is on the move.

runC is the core run-time container code that lives underneath several open-source container management systems like Docker, Kubernetes, ContainerD and CRI-O. Its widely being used by major cloud hosting and server providers.
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 doesnt 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 to this.
Red Hats 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 containerized environment.
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 containers user namespace). The docker package as well as podman are protected against this exploit because they run container processes as container_t.
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 the host).
Tim Mackey, technical evangelist at Synopsis, has reflected on what this vulnerability means to the enterprise.
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, thats still easier than it should be. Then the legitimate app developer merges their app with that malicious base image and youve 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 other processes.
— Larry Loeb has written for many of the last centurys major dead tree computer magazines, having been, among other things, a consulting editor for BYTE magazine and senior editor for the launch of WebWeek.

Last News
▸ ArcSight prepares for future at user conference post HP acquisition. ◂ Discovered: 07/01/2025 Category: security	▸ Samsung Epic 4G: First To Use Media Hub ◂ Discovered: 07/01/2025 Category: security	▸ Many third-party software fails security tests ◂ Discovered: 07/01/2025 Category: security

**Cyber Security Categories**
Google Dorks Database	Exploits Vulnerability	Exploit Shellcodes

CVE List

Tools/Apps

News/Aarticles

Phishing Database

Deepfake Detection

Trends/Statistics & Live Infos

Tags:
Container Vulnerability: Still a Reality