A serious vulnerability in runC, a widely used CLI tool for spawning and running containers, could be exploited to compromise the runC host binary from inside a privileged runC container, allowing the attacker to gain root access on the underlying host system.
RunC is the container runtime underneath infrastructure and engines such as Docker, CRI-O, containerd, Kubernetes, etc.
About the vulnerability (CVE-2019-5736)
CVE-2019-5736 was reported by researchers Adam Iwaniuk and Borys Popławski to runC maintainers, who immediately started working on a fix.
“The vulnerability allows a malicious container to (with minimal user interaction) overwrite the host runc binary and thus gain root-level code execution on the host,” Aleksa Sarai of the runC team explained.
“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.”
He additionally discovered that a similar vulnerability exists in LXC and Apache Mesos. He says that it likely affects most other container runtimes “unless they took very strange mitigations before-hand.”
Red Hat has warned users about the need for updating the “docker” and “runc” packages (with additional information about the impact of the flaw). Debian and Ubuntu are in the process of releasing fixes.
AWS has issued an advisory for users of its various offerings (Amazon Linux, Amazon ECS, Amazon EKS, AWS Fargate, etc.) with instructions and advice on how to plug and/or mitigate the hole. Google Cloud did the same.
The vulnerability’s impact
The runC team assigned a CVSSv3 score of 7.2 to the flaw, but its severity will vary depending on integrations, configurations and existing mitigations.
Twistlock CTO John Morello says that, arguably, this is the most important CVE in the container space in years.
“It’s a real threat that can be relatively easily exploited if an organization runs images from untrusted sources and can lead to complete host take over. Given the relatively simplistic attack vector and the fact that exploit code will be released in 1 week, it’s highly likely this will be weaponized quickly,” he told Help Net Security.
“Most default configurations of container environments are vulnerable to this exploit until patched. There are some key mitigations, like not running untrustworthy images, that can significantly reduce the likelihood of exploit.”
He doesn’t expect this flaw to affect container adoption. “The security track record of container platforms has generally been pretty good relative to existing platforms anyway – some of the mitigations container platforms enable to control namespace usage can effectively mitigate this problem when properly configured,” he noted.
Scott McCarty, principal product manager for the container subsystem team at Red Hat, noted that this isn’t the first major flaw in a container runtime to come to light and it’s unlikely to be the last.
“Just as Spectre/Meltdown last year represented a shift in security research to processor architectures from software architectures, we should expect that low-level container runtimes like runC and container engines like Docker will now experience additional scrutiny from researchers and potentially malicious actors as well,” he concluded.
“As the industry and our customers move to hyper-dense architectures, escapes and privilege escalations like this vulnerability (CVE-2019-5736) have a broader scope of impact than privilege escalations on a traditional bare-metal system. Instead of compromising one system, containerization broadens the scope of potential threat vectors,” commented Chris Robinson, program manager, Product Security Assurance, Red Hat.
“Thankfully, for Red Hat customers, Red Hat Enterprise Linux provides a more secure foundation underpinning our cloud and container products, and default SELinux policies help to mitigate this issue for our users, so that they can plan business-appropriate times to schedule deploying the updated software that includes the flaw fixes. ”
UPDATE (February 13, 2019, 2:20 AM PT):
“Someone outside of the embargo has posted a PoC of the exploit for CVE-2019-5736 (which is related though not using the same vector). Since the original researchers have posted a blog post explaining the exploit in some detail, I’ve decided to post the exploit code early – since the cat is out of the bag anyway,” Sarai announced on the Open Source Security Mailing List.