4

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?

  • I'm not sure I follow the question. Can you clarify? My confusion at the moment is if you are not looking at the code inside the container, where are your concerns? I'm just not sure I fully know where you are going with this particular question. – h4ckNinja Dec 22 '16 at 1:03
  • I was worried it might be possible to e.g. build a docker image that automatically inherits environment variables from the host environment by putting some special directive into the Dockerfile. Or to build a docker image that runs a command in the host environment before starting. Or something like that. – Alex Flint Dec 22 '16 at 1:07
5

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.

3

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.
  • This would be a pretty good answer if it had CVE examples. Also, I believe that kernel panic is just a special case of DoS (sorry for being pedantic). – grochmal Dec 22 '16 at 1:25
  • @grochmal Normally I just lurk this stack exchange but as someone who uses docker almost daily in production and development environments, I felt obliged to give some examples (damaging the host) that are so easy that they happen accidentally. – Lan Dec 22 '16 at 2:56
  • @grochmal You're probably correct about a kernel panic being a DoS; I separated them merely because hogging CPU or files IDS is only temporally disruptive whereas I've seen a kernel panic caused by a container easily brick a server. – Lan Dec 22 '16 at 3:04

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.