RunC Bug Highlights Docker Security Challenges, But It’s Not Fatal

It’s a Docker admin’s worst nightmare: An attacker compromises a container, then uses it to gain control of the entire host server. A newly discovered security vulnerability in runC enables just that type of attack—at least in theory.

The vulnerability, CVE-2016-9962, allows a process running inside a container to discover information about file descriptors on the host. Theoretically, this information could be used to gain access to file system data on the host. From there, an attacker could ultimately execute “a complete container escape by leveraging memory access or syscall interception,” according to the vulernability documentation.

The root of the problem lies with runC, the container runtime used by Docker. As Aqua Security explains:

There is a (very) small “window” of opportunity, before the runc init process execs the command inside the container, where the container has access to the runc init process on the host. This is because runc enters the namespace of the container before it execs the final command. This window could enable a container, for example, to list file descriptors on the host process, which can then lead it to the host’s file system. Because many containers run as root, this indeed has serious implications.

Bad News for Docker Security

For a long time, people have been noting that containers don’t isolate the application environment as strictly from the host as virtual machines do. For that reason, some have concluded that “one can lose some aspects of isolation” when using Docker.

Previously, claims that Docker is less secure because containers are not as strictly isolated were based mostly on theoretical scenarios of undiscovered vulnerabilities that could exist. Now, this bug shows that such security flaws actually do exist.

This also happens to be one of the first major security vulnerabilities that affect Docker containers. That makes it especially likely to generate at least some amount of panic, especially among people who were predisposed to believe that Docker containers are fundamentally less secure than traditional infrastructure.

But the Sky is not Falling

But as with most publicly disclosed security vulnerabilities, the sky is not falling. While the theoretical implications of this bug are serious, there is no indication that it is has been exploited in the wild to compromise real-world servers.

Plus, in this case, the worst-case scenario that could result from the vulnerability—a full-scale takeover of a Docker host server—requires a large amount of escalation. The basic exploit would just give an attacker glimpses into the host file system. From there, a lot more work is needed to run amok on the host.

This makes the runC security bug less worrying than, say, Heartbleed, a major vulnerability that existed for a long time on thousands of production servers. No one died because of heartbleed. This runC bug will also be non-fatal.

Bottom line: Docker containers, like all major technologies, have security vulnerabilities. But there is no reason to think Docker is less fundamentally secure than other types of infrastructure technology. After all, applications hosted on bare-metal servers are even less isolated from the host than containerized apps are, and no one is claiming that bare-metal servers are inherently insecure.

Christopher Tozzi

Christopher Tozzi has covered technology and business news for nearly a decade, specializing in open source, containers, big data, networking and security. He is currently Senior Editor and DevOps Analyst with Fixate.io and Sweetcode.io.

Christopher Tozzi has 254 posts and counting. See all posts by Christopher Tozzi