One of the great security fears about containers is that an attacker could infect a container with a malicious program, which could escape and attack the host system. Well, we now have a security hole that could be used by such an attack: RunC container breakout, CVE-2019-5736.
Also: This is how Docker containers can be exploited
RunC is the underlying container runtime for Docker, Kubernetes, and other container-dependent programs. It's an open-source command-line tool for spawning and running containers. Docker originally created it. Today, it's an Open Container Initiative (OCI) specification. It's widely used. Chance are, if you're using containers, you're running them on runC.
According to Aleksa Sarai, a SUSE container senior software engineer and a runC maintainer, security researchers Adam Iwaniuk and Borys Popławski discovered a vulnerability, which "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 doesn't matter if the command is not attacker-controlled) as root."
To do this, an attacker has to place a malicious container within your system. But, this is not that difficult. Lazy sysadmins often use the first container that comes to hand without checking to see if the software within that container is what it purports to be.
How bad is this? As bad as you can imagine. Scott McCarty, Red Hat technical product manager for containers, warned:
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. 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."
Besides runC, Sarai reports that the problem can also attack container systems using LXC and Apache Mesos container code. So, yes, if you're running any kind of containers, you need to patch ASAP.
Most, if not all, cloud container systems are vulnerable to this potential attack. Amazon Web Services (AWS), for example, states that while there's a patch available for Amazon Linux, patches are still being rolled out for Amazon Elastic Container Service (Amazon ECS), Amazon Elastic Container Service for Kubernetes (Amazon EKS), and AWS Fargate.
Red Hat claims that if you deploy SELinux, this bug shouldn't bother you. However, while you should run SELinux, and it's set on by default in Red Hat Enterprise Linux (RHEL), many sysadmins don't run it because it's difficult to maintain.
In addition, Sarai notes, "This vulnerability is *not* blocked by the default AppArmor policy, nor by the default SELinux policy 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 container's user namespace)."
A Red Hat representative clarified, "that is only true for the "moby-engine" package on Fedora. The "docker" package as well as podman are protected against this exploit because they run container processes as container_t. as opposed to container_runtime_t which is what moby uses. RHEL doesn't ship Moby at all, so the vulnerability is completely mitigated by SELinux in enforcing mode."
The quick and easy answer is to patch runC as soon as possible.
Well? What are you waiting for? Get on it. This has the potential to seriously damage your systems.
These are the worst hacks, cyberattacks, and data breaches of 2018