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 read www.docker.com/resources/security.

Update and mea culpa:

After reviewing further we have discovered that our legacy LXC code is still vulnerable to this issue. We haven’t used LXC as the default container format since Docker 0.9 when we replaced it with libcontainer. It is still available, however, in the Docker 1.0 codebase albeit unused. We’ve since updated this code to fix the issue and released Docker 1.0.1 with the fixes.

12 Responses to “Docker Container Breakout Proof-of-Concept Exploit”

  1. Adrien

    What exactly do you mean by “Not run untrusted applications with root privileges”? Should we not run unstrusted applications at all because they will have root privileges or do you suggest to change the userid before running such an application? How would you do that?
    Thanks,

    Reply
    • Viktor Petersson

      Ideally you use the ‘USER’ setting to make the processes run by ‘nobody’ or some other unprivileged user. Most processes will run just fine like that. Also, remember that you can use a different port in the container than the one you expose to the host.

      Reply
  2. Docker containers spring a leak: Already fixed in 1.0 release | SiliconANGLE

    […] you wish to open and then extract sensitive information like passwords,” wrote Docker in a blog post after the flaw was […]

    Reply
  3. Adrien

    Ok , I found the -u option for “docker run”, which allows running with another uid than root. Sorry.

    Reply
  4. DevSoup.co.uk | Update Docker on MacOS

    […] Docker is now 1.0, and I was using 0.11 (which has a vulnerability which allows programs to break out from their Docker container), it’s time to upgrade my version running on […]

    Reply
  5. Joyent Joins Containers Debate – InformationWeek | Everyday News Update

    […] the possible breakout of malicious code from earlier versions of Docker containers, as it did in a blog post June […]

    Reply
  6. Joyent Joins Containers Debate – InformationWeek | News Update

    […] the possible breakout of malicious code from earlier versions of Docker containers, as it did in a blog post June […]

    Reply
  7. Joyent Joins Containers Debate – InformationWeek | Headline News Extra

    […] the possible breakout of malicious code from earlier versions of Docker containers, as it did in a blog post June […]

    Reply
  8. The Ship Show | Quantifying Quality

    […] Docker suffers container breakout proof-of-concept; see the line by line analysis […]

    Reply
  9. Bill Riemers

    The biggest security problem with docker-io is not docker itself, but the lack of sound security standards administrators understand. You can find many websites that talk about adding users to the dockers group, so they can run their own docker containers, but they fail to mention that effectively this gives the user root priviledges. One of the simpliest ways for docker user to gain root on the host us to use a volume so they can chmod +s on an executable on the host. This simplest approach can be defeated by SELinux, provided you make sure you only change attributes to allow partitions to be used as volumes if that are mounted with nosuid. But lets face it, most administrators aren’t even going to think of that detail.

    Reply

Leave a Reply