Attack vectors when running untrusted docker images

Question

What are the possible attack vectors if I am running user-submitted docker image, e.g. pull via docker pull FOO; ... docker run FOO where FOO is a user-submitted string containing the name of a Docker Hub repository?

This is not a question about simply running untrusted code inside docker containers. I actually already understand the security implications of that well enough for now. What are the additional attack vectors relevant to running untrusted images?

Answer 1

There's various ways that a rogue container might be able to damage the host or other containers on the network, depending on the configuration of the docker daemon.

• By default all containers share the same network. As such a rogue container can attempt to attacker other containers. This could include attacks like ARP poisoning depending on the rights provided to the container.
• On the network front, a rogue container has a potentially privileged position in your environment and could try to attack other systems on connected networks.
• A rogue container can attempt to escalate privileges to compromise the host operating system. This is generally achieved by attempting to exploit kernel vulnerabilities in the host kernel. An important point about container isolation is that all running containers share the same kernel.
• On that note, if the kernel exposes any sensitive information to the containers (e.g. information from the /proc filesystem) it might be possible for the rogue container to get access to that.
• If the container is executed with certain configurations, e.g. --privileged or mapping the docker socket into the container, it becomes trivial for the rogue container to take over the host.

I'd recommend reading the CIS Security benchmark for docker to get some more information and suggestions for hardening your installation, if you're interested.

Answer 2

It depends the specific version of docker and the containers you are running. And how you are using your containers.

While the dream is that a container is isolated from the host, there have been times when a bug or vulnerability has been discovered that has allowed a container to gain root access to the host system or, more commonly, being able to damage the host. Easy ways to damage the host:

• Getting a container to cause a kernel panic on the host.
• Denial of service (there are various resources that a container can hog to starve the host's other systems).
• A developer, perhaps foolishly, mounting a volume as read/write and the dangerous container damaging or obscuring something.

The roles of your containers also add additional security vulnerabilities:

• Say if a tiny-proxy docker container is a poisoned image. Suddenly you could have an interloper tracking all the requests in the network and determining your topology.
• Or perhaps your containers talk to each other on an encrypted private network and without authentication. One poisoned image as a layer to one of your custom containers is a key to compromising the whole system.
• Or maybe your vault docker container is the rouge image. Now you've just feed your keys to a phony container.