Evil Docker Images

Don’t run these at home (or work, or at all…)

Erica Windisch
Feb 20, 2014 · 3 min read

Having followed various trends in new Dockerfile commands and have been thinking of ways to break the system. As an exercise, I’ve created a few evil images.

Bitcoin Tipping Image

This image is simultaneously the least and most evil of them all. The image itself should you run it will be an Ubuntu system containing a bitcoin miner. That’s not very evil, there are already bitcoin mining images and one might have purpose to run such an image.

What makes this “tipping image” evil is that it steals 2 minutes of time from your CPU for bitcoin mining whenever you build an image derived from it. It isn’t terribly transparent about what it is doing as it does it to anyone that watches the build, but it is throughly transparent to the image that is derived from it.

For instance consider this Dockerfile & build:

echo “FROM ewindisch/bitcoin-tipping-image” > Dockerfile;
docker build .

When you build your Dockerfile, an “ONBUILD” will trigger, running a bitcoin mining operation for 2 minutes, then will exit and will load a pristine Ubuntu:precise image. Your final image will not contain the bitcoin mining application or any artifacts of it.

Source: https://github.com/ewindisch/docker-tipping-image

Infinite, recursive Docker runs

It is possible to use docker-in-docker to create something similar to a fork-bomb. Docker can be nested inside of Docker until the system runs out of file-descriptors, processes, or whatever other limits it might find.

In terms of “evil” rating, I’d rank this pretty low since you’re “asking for it” whenever you pass ‘-priviledged”. Furthermore, there is nothing that prevents any container from executing a fork-bomb or other nastiness. Still, it’s an interesting exercise.

You’d do this using:

docker run -t -i -v /var/lib/docker -privileged ewindisch/docker-bomb

This image is a quite a bit more bloated than it should be and has proven to be quite slow, having to pull hundreds of megabytes from the Docker Index each time it runs. This could be slimmed down considerably which would make this both faster and more effective at crashing your OS.

Source: https://github.com/ewindisch/docker-bomb

Infinite builds

This one sits between the docker-in-docker and tipping builds in terms of evilness. It exploits what is arguably a bug in Docker builds that allows the build to spin. There are tons of ways to make Docker builds spin out of control, but few actually crash the Docker daemon itself. This is of the latter variety.

Using this is as simple as building the following Dockerfile / build:

echo “FROM ewindisch/circle” > Dockerfile;
docker build .

When you build a Dockerfile containing this FROM line (which may be placed anywhere in the build), you’ll see this:

# Executing 1 build triggers
Step onbuild-0 : FROM ewindisch/circle
# Executing 1 build triggers
Step onbuild-0 : FROM ewindisch/circle
# Executing 1 build triggers
Step onbuild-0 : FROM ewindisch/circle
# Executing 1 build triggers
Step onbuild-0 : FROM ewindisch/circle

Source: https://github.com/ewindisch/docker-circle

Final remarks:

You’re welcome ;-)

    Erica Windisch

    Written by

    CTO and founder of IOpipe, Inc. working on Application Operations tools for serverless applications.

    Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
    Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
    Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade