Container Security Holes

We can’t think of a better way to put it then the ZDNet article [1]:

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.

Root access to host filesystem

Container vulnerabilities have recently been popping up like mushrooms in the rain. On May 23rd, 2019, researcher and runC maintainer Alexa Sarai has reported a vulnerability that enables an attacker to gain write access anywhere on the host. Add a couple of steps to it and the attacker would be able to execute code on the host, tamper with the execution of other containers, and so on.

RunC breakout to root

Earlier, in February 2019, security researchers Adam Iwaniuk and Borys Popławski have discovered a vulnerability that applies to multiple container frameworks, including Docker (Swarm and Kubernetes clusters are affected), LXC and Apache Mesos. It enables an attacker to break out of a container, and gain root privileges on the host. That, in tun, could enable an attacker to attack the rest of the infrastructure, or to turn to other containers on the host, and compromise the security and privacy of business critical applications.

To understand the industry impact of this vulnerability, it is best to see the quote by Scott McCarty, technical product manager for containers at RedHat:

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.

It means that managed container services where your application is likely running alongside applications of other users, may not provide appropriate confidentiality and privacy guarantees until the vulnerability is patched.

RunC maintainer Alexa Sarai responded to the disclosure and provided a patch that mitigates the vulnerability. LXC and Mesos containers might still be vulnerable. More importantly though, the general problem underlying this particular case, is a lack of adequate isolation between containers on the same host, remains a huge concern.

This disclosure follows shortly after the finding of a major Kubernetes vulnerability disclosed in December and adds up to a series of sobering realizations regarding container security.

Mitigation with Anjuna

Using Anjuna, one doesn’t have to throw the baby (the ease of deploying applications with containers) with the bathwater (container security issues). Anjuna enables to easily run your container applications inside a secure enclave that provides hardware-grade isolation from anything else on the host, regardless of the infrastructure security, or the security of the container framework. The secure enclave technologies leveraged by Anjuna ensure that even an attacker that successfully escaped the container, and obtained root-level access to the host would not be able to access your application’s data at runtime or at-rest.

References

[1] https://www.zdnet.com/article/doomsday-docker-security-hole-uncovered/
[2] https://thenewstack.io/critical-vulnerability-allows-kubernetes-node-hacking/
[3] https://duo.com/decipher/docker-bug-allows-root-access-to-host-file-system