#Docker Container Breakout #Proof-of-Concept #Exploit
At Docker we take security very seriously and try to be as transparent as possible. This morning proof of concept exploit code was published showing how to break out of a Docker Engine 0.11 container.
- We want to emphasize that this vulnerability only applies to users who are running Docker Engine in a non-recommended way by running untrusted applications with root privileges inside containers.
- We want to be clear that Docker Engine 1.0 is not vulnerable to this exploit. We strongly recommend that users upgrade Docker Engine to version 1.0 to address this issue and be on a fully supported, production-ready platform.
The proof of concept exploit relies on a kernel capability that allows a process to open any file in the host based on its inode. On most systems, the inode of the / (root) filesystem is 2. With this information and the kernel capability it is possible to walk the host’s filesystem tree until you find the object you wish to open and then extract sensitive information like passwords.
In earlier Docker Engine releases (pre-Docker Engine 0.12) we dropped a specific list of kernel capabilities, ( a list which did not include this capability), and all other kernel capabilities were available to Docker containers. In Docker Engine 0.12 (and continuing in Docker Engine 1.0) we drop all kernel capabilities by default. Essentially, this changes our use of kernel capabilities from a blacklist to a whitelist.
This change mitigates the specific exploit published this morning. Please remember, however, that at this time we don’t claim that Docker Engine out-of-the-box is suitable for containing untrusted programs with root privileges. If you use Docker Engine in such a scenario, you may be affected by a variety of well-known kernel security issues. Instead, we specifically recommend that you:
- Run Docker Engine with AppArmor or SELinux to provide containment;
- Map groups of mutually-trusted containers to separate machines; and
- Not run untrusted applications with root privileges.
Also, note that Docker Engine will also soon support user namespaces which will provide a further layer of security for your containers.
We also want to remind people of our security policy. Docker supports responsible disclosure of security vulnerabilities. We’re happy to fully disclose all details of a security vulnerability but in the interests of responsible disclosure we ask security researchers and reporters to allow us sufficient time to patch the vulnerability before publishing the details. We will provide credit to any researcher or reporter who provides details of an vulnerability to us. You can report issues to the security@docker.com email address.
For a full discussion of security best practices with Docker, please readwww.docker.com/resources/security.
