Jump to content

RunC Flaw Lets Attackers Escape Linux Containers to Gain Root on Hosts

The AchieVer

Recommended Posts

RunC Flaw Lets Attackers Escape Linux Containers to Gain Root on Hosts

linux container runc docker hack
A serious security vulnerability has been discovered in the core runC container code that affects several open-source container management systems, potentially allowing attackers to escape Linux container and obtain unauthorized, root-level access to the host operating system.

The vulnerability, identified as CVE-2019-5736, was discovered by open source security researchers Adam Iwaniuk and Borys Popławski and publicly disclosed by Aleksa Sarai, a senior software engineer and runC maintainer at SUSE Linux GmbH on Monday.

The flaw resides in runC—a lightweight low-level command-line tool for spawning and running containers, an operating-system-level virtualization method for running multiple isolated systems on a host using a single kernel.

Originally created by Docker, runC is the default container run-time for Docker, Kubernetes, ContainerD, CRI-O, and other container-dependent programs, and is widely being used by major cloud hosting and server providers.

runC Container Escape Vulnerability [CVE-2019-5736]

Though researchers have not yet released full technical details of the flaw to give people time to patch, the Red Hat advisory says the "flaw was found in the way runC handled system file descriptors when running containers."

Thus, a specially-crafted malicious container or an attacker having root access to a container could exploit this flaw (with minimal user interaction) to gain administrative privileges on the host machine running the container, eventually compromising the hundreds-to-thousands of other containers running on it.

For root access to the container, the attacker has to either:
  • create a new container using an attacker-controlled image, or
  • attach (docker exec) into an existing container which the attacker had previous write access to.
"A malicious container [then] could use this flaw to overwrite contents of the runC binary and consequently run arbitrary commands on the container host system," the advisory states.

How bad is this vulnerability?

Scott McCarty, principal product manager for containers at Red Hat, says, "While there are very few incidents that could qualify as a doomsday scenario for enterprise IT, a cascading set of exploits affecting a wide range of interconnected production systems qualifies...and that’s exactly what this vulnerability represents."

runC Flaw: Security Patch Updates and Mitigation

According to Red Hat, the vulnerability can be mitigated if SELinux in targeted enforcing mode is enabled, which is default on RedHat Enterprise Linux, CentOS, and Fedora.

The maintainers of runC have published a git commit to resolving the security flaw, but all the projects built atop runC need to incorporate the patches in their products.

Debian and Ubuntu have also acknowledged that their Linux distributions are vulnerable to the reported vulnerability. The issue also affects container systems using LXC, a Linux containerization tool that predates Docker, and Apache Mesos container code.

Major vendors and cloud service providers have already been pushing out security patches to address the issue, including GoogleAmazonDocker, and Kubernetes.

Rancher, the creator of the open-source Kubernetes management software, has also published a patching script for legacy versions of Docker.

If you are running any kind of containers, consider yourself vulnerable and upgrade to an image with a fixed version of runC as soon as it is available to prevent cyber attacks.




Link to comment
Share on other sites

  • Replies 2
  • Views 447
  • Created
  • Last Reply

The disclosure of a security flaw (CVE-2019-5736) in runc and docker illustrates a bad scenario for many IT administrators, managers, and CxOs. Containers represent a move back toward shared systems where applications from many different users all run on the same Linux host. 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.

For many Red Hat end users, it’s unlikely that this flaw gets that far. IT organizations using Red Hat Enterprise Linux to underpin their Linux container and cloud-native deployments are likely protected, thanks to SELinux. 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.

This isn’t the first major flaw in a container runtime to come to light and, as container deployments and interest in associated technologies increase, 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.

To me, the underlying message here is: Containers are Linux.

Not exactly a newsworthy statement, I know, but it’s something that can be easily forgotten in modern IT, especially with the relative ubiquity of cloud-based container services and “throwaway” operating systems serving as container hosts. No matter the other bells, whistles and shiny objects that surround your container infrastructure, if your host layer isn’t properly updated and secured, your operations are likely at risk.

As far as container runtimes go, runc is used by just about every container engine out there - it’s a fundamental component of even the most basic Linux container implementations as a low-level runtime. As you might suspect by the name, this is a function that actually “runs” a given container and there is tight coupling between the features offered in runc and the Linux kernel. The OCI Runtime Specification is based on runc, and the runtime is used across a wide range of container infrastructure and Kubernetes offerings, including Red Hat OpenShift Container Platform.

But Linux still serves as the foundation, and that foundation, as today’s vulnerability illustrates, still really matters. Red Hat Enterprise Linux is the bedrock for Red Hat’s entire portfolio of solutions, providing a more secure building block for traditional and cloud-native infrastructure deployments. The world’s leading enterprise Linux platform is configured with secure defaults, such as SELinux enabled and in enforcing mode, at installation.

This commitment to security at the most basic level of operations means that users of most Red Hat technologies are not affected by this vulnerability as long as SELinux is in enforcing mode. As noted earlier, this is a default setting on Red Hat Enterprise Linux as well as Red Hat OpenShift, meaning that many customers can be protected against specific vulnerabilities, like today’s, without doing anything on their end.

End users should still patch the affected components. As Red Hat subscribers, this should be a relatively painless process thanks to Red Hat’s expertise in delivering enterprise-grade open source solutions. We don’t just spit out patches direct from the community - we analyze, test, harden and validate the code before it makes to users of our products, helping to limit the potential issues that can arise from patching production systems.

As infrastructure becomes more dense and containerized processes and applications impact more than just isolated systems, layered security measures become very important. It’s not just about having a firewall or access control or a vulnerability content scanner - modern IT deployments require stepped security measures addressing all levels of a software stack.

And again, even with containers, it all starts with Linux.




Link to comment
Share on other sites


This topic is now archived and is closed to further replies.

  • Recently Browsing   0 members

    • No registered users viewing this page.
  • Create New...