Runc, a building-block project for the container technologies used by many enterprises as well as public cloud providers, has patched a vulnerability that would allow root-level code-execution, container escape and access to the host filesystem.
Discovered by researchers Adam Iwaniuk and Borys Popławski, 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,” according a posting on Monday.
An attacker with local access to the affected system can exploit the flaw by convincing users to run malicious or modified containers on their systems. One of runc’s administrators, Aleksa Sarai, who is also a senior software engineer at SUSE Linux GmbH, explained in the posting that an attacker could create a new container using an attacker-controlled software image, or could add any container command (i.e., the “docker exec” command line in Docker) into an existing container that he or she has write access to; from there, the attacker needs only to convince a user to run the weaponized container within their environment, via various social engineering tactics.
“This vulnerability overwrites the `runc` binary which is a CLI tool used for starting and running containers,” Ali Golshan, CTO and co-founder at StackRox, explained to Threatpost. “This method allows the attacker to have root access to the environment, with the eventual goal of exploiting things like zero-day vulnerabilities to enable code-execution. This could allow an attacker to run new containers, exhaust resources or gain access to existing containers.”
Impact
runc is the open-source underlying container runtime that powers popular container technologies like Docker, cri-o, containerd and Kubernetes. The vulnerable surface is thus potentially vast: Containers allow applications to be more agile and on-demand, and as such have become a de facto standard for architecting cloud services, embraced by enterprises worldwide as well as Amazon Web Services, Microsoft Azure and other cloud providers.
Scott McCarty, principal product manager for containers at Red Hat, noted that the flaw represents “a bad scenario for many IT administrators, managers and CxOs,” because of the interconnectedness of container-based cloud infrastructure.
“Containers represent a move back toward shared systems where applications from many different users all run on the same Linux host,” he said in a Monday blog. “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. A cascading set of exploits affecting a wide range of interconnected production systems qualifies as a difficult scenario for any IT organization and that’s exactly what this vulnerability represents.”
Golshan told Threatpost, “while this is a vulnerability there are comments within the release that ‘correct use of user namespaces can prevent this; where the host root is not mapped into the container’s user namespace.’ This is a good example of how attack surface can move to the container and orchestrator ecosystem due to a more immature security posture.”
Who’s Affected and Patch Availability
By default, Red Hat products are protected by SELinux in enforcing mode; but the vulnerability is not blocked by the default AppArmor policy, nor by the default SELinux policy in the “moby-engine” package on Fedora (Fedora’s “docker” package as well as podman are protected, however).
Related container projects like Apache Mesos and LXC have similar vulnerabilities, according to Sarai; the latter has also patched the issue. But the systemd-nspawn project isn’t vulnerable because its method of attaching to a container uses a different method to LXC and runc, Sarai said.
“It is quite likely that most container runtimes are vulnerable to this flaw, unless they took very strange mitigations beforehand,” said the researcher.
AWS has also issued a security bulletin and patches for its platforms that use runc.
The flaw carries a CVSS severity rating of 7.2.
Container Security in the Spotlight
Container security has been an increasing topic of late; in January for instance, researchers said they hacked the Docker test platform called Play-with-Docker, allowing them to access data and manipulate any test Docker containers running on the host system.
Last year, several malicious Docker images (17 in total) were pulled down from the Docker Hub image repository. Researchers couldn’t say for sure how many times the rogue containers were used by Docker Hub users, but Kromtech estimates that the 17 images were downloaded collectively 5 million times during the year they were available.
And Docker last year patched a privilege escalation vulnerability that could also have lead to container escapes, allowing a hacker to affect operations of a host from inside a container.
Enterprises also report an accelerating number of container attacks. In fact, 60 percent of respondents in a recent survey admitted that their organizations had been hit with at least one container security incident within the past year. In companies with more than 100 containers in place, that percentage rises to 75 percent.
