The Docker Linux container format has a major exposure that could allow malicious code to assume unassigned privileges with the host server and order the extraction of files that are not intended to be accessible to the container's code.
Several generations of the Docker container formatting system are subject to the vulnerability; only the latest version, Docker 1.3.2, is exempt. There's no way to patch the thousands of copies of Docker with release numbers before the 1.3.2 release, according to company representatives -- the only safeguard is to upgrade to the recent release.
The 1.3.2 release can be downloaded here.
The exposure was discovered by security researcher Florian Weimer at Red Hat and confirmed by independent security researcher Tonis Tiigi. Red Hat is deeply committed to Linux users' adoption of Docker and produced Atomic Host, a version of Red Hat Enterprise Linux geared to run containers.
Docker's Erich Windisch issued a security advisory on Nov. 24 about the defect: "The Docker engine, up to and including version 1.3.1, was vulnerable to extracting files to arbitrary paths on the host during 'docker pull' and 'docker load' operations ... This vulnerability could be leveraged to perform remote code execution and privilege escalation." Windisch added that no remediation is available for older versions of Docker.
[Want to learn more about how containers have become important to the Amazon cloud? See Amazon's Container Strategy Examined.]
"While it is in no way an indictment of the Docker project, it does show that early-stage projects are just that -- early and still a little rough around the edges," wrote Ben Kepes, a New Zealand-based consultant on cloud computing at Diversity Ltd. on his Forbes.com blog. He added that news of the exposure is "a cautionary tale for organizations experimenting with early-stage projects."
Docker security has long been a concern for those familiar with the intricacies of running dozens of containers together on a single host. Containers are an effective way to isolate one application from another on a shared host, provided no container contains code that actively tries to trespass across container boundaries. The exposure found in versions of Docker up to 1.3.1 allowed that to happen.
Despite developer enthusiasm for its formatting system, Docker has warned that protections against malware from one container to the next can't be guaranteed and recommended that only containers from a single owner should be run on the same host. VMware representatives, including CTO Ben Fathi, reiterated that warning at VMworld in August, stating again that only containers running inside a virtual machine on a shared host should be considered secure.
The release of 1.3.2 code fixed a second but lesser security hole as well, Windisch's post indicates.
There has been a background debate over whether multiple workloads can run safely on a single host in containers or whether enterprise IT stick should with virtual machines. Containers represent a significant advance in efficiency for multiple workloads because they use a single host's operating system kernel.
A virtual machine is more self-contained. It includes its own operating system but requires more system memory and compute cycles.
For now, virtual machines are winning the security debate on multi-tenant hosts. But developers and IT managers are watching Docker to see if container security improves. Managers at the Joyent cloud say their containers running under the SmartOS version of Solaris create a secure form of multi-tenant container operation. Where dozens of virtual machines can be put on a single host, hundreds of containers can be run on the same server resources.
Malicious software is morphing to be more targeted, stealthy, and destructive. Are you prepared to stop it? Get the Malware Mutation issue of Dark Reading today.