A vulnerability recently addressed in runc could allow malicious containers to gain root-level code execution on the host.
Introduced in 2015, runc is a lightweight, portable container runtime that includes all of the code used by Docker to interact with system features related to containers. The runtime is used in most containers out there, including cri-o, containerd, Kubernetes, Podman, and others.
Tracked as CVE-2019-5736 and featuring a CVSSv3 score of 7.2, the vulnerability can be exploited with minimal user interaction, senior software engineer at SUSE Linux and runc maintainer Aleksa Sarai says.
Discovered by Adam Iwaniuk and Borys Popławski, the vulnerability could allow a malicious container to overwrite the host runc binary and execute code on the host.
The bug can be triggered when creating a new container using an attacker-controlled image, or when attaching to a running container (using docker exec) that the attacker previously had write access to.
“Exploiting this vulnerability means that malicious code could potentially break containment, impacting not just a single container, but the entire container host, ultimately compromising the hundreds-to-thousands of other containers running on it,” Scott McCarty, Red Hat principal product manager for containers, says.
The use of SELinux in targeted enforcing mode prevents this vulnerability from being exploited. However, the default AppArmor policy and the default SELinux policy on Fedora (only the moby-engine package) fail to prevent the bug, Sarai says.
Only privileged containers (root privilege on the host is required) can exploit the flaw (unprivileged containers with a non-identity ID mapping don’t have permission to write to the host binary).
The vulnerability impacts runc releases through 1.0-rc6, as used in Docker before 18.09.2 and other products. The vulnerability occurs because of file-descriptor mishandling, related to /proc/self/exe.
A GitHub repository was created to provide a backport of patches for older versions of runc that were packaged with Docker.
Exploit code for the vulnerability is expected to be published within a week. A Shodan search shows that there are nearly 4,000 exposed Docker daemons on the internet.