How secure is Docker?

Discussion about Docker security and docker vulnerabilities.

Docker introduction :

Docker is an OS virtualization software platform that is used to create, deploy and run applications in a Docker container. It is very lightweight when compared to a virtual machine and it allows us to wrap up our application in a container along with all the required libraries and other dependencies and deploy it, so it reduces dependency-related conflicts. Docker helps in the simplification and acceleration of workflow.

Two components of docker:

  1. Docker Image.
  2. Docker Container.
  • A Docker image is a read-only template that contains a set of instructions for creating a container that can run on the Docker platform. It provides a convenient way to package up applications and preconfigured server environments, which you can use for your own private use or share publicly with other Docker users.
  • Image is an executable package that includes everything needed to run an application -the code, runtime, libraries, environment variables, and configuration files.

How docker isolates itself?

Linux Cgroups is one of the kernel features provided by Linux, which helps docker to isolate itself. Cgroups allow us to group a set of related processes which can run as a single unit. We can control this group of processes in terms of usage CPU utilization, memory, I/O. Cgroups can have control over the allocation, managing and monitoring of system resources. Hardware resources can also be divided among the tasks and the users which increases efficiency.

Is Docker secure?

Most of the newbie developers think that docker is secure and they don’t even do a basic scan of the image which they pulled from the docker hub(docker hub is the world’s largest library and community for container images Browses over 100,000 container images from software vendors, open-source projects, and the community.)Most of the people run randomly Docker images on their system without caring who pushed it or about their authenticity. Docker is not as secure as a virtual machine because a virtual machine does not talk to the host kernel directly. They do not have any access to kernel file systems like /sys and /sys/fs,/proc/*.

Open attack surfaces for Docker containers:

  • If the attacker is the one who can start containers (i.e., has access to the Docker API), then he immediately, without further action, has full root access to the host. This is well known for years, has been proven, and is not under debate by anyone (Google or SE immediately give you simple command lines which do not need a particular container to work)
  • If the attacker manages to get root inside the container, then you’re in trouble. In effect, he/she can then do pretty arbitrary kernel calls and try to affect the host kernel. Unfortunately, many docker images seem to run their stuff as root and skip the USER in the Dockerfile — this is not a Docker problem but a user problem.
  • Vulnerabilities in the kernel Containers on a server share the same kernel as the host, so if the kernel has an exploitable flaw, it could be used to break out of the container and into the host.
  • If you have a Bad configuration then you have access to a container that is running with — privileged, you are most likely be able to gain access to the underlying host.
  • If you have a container that mounts a host filesystem, you can probably modify things in that filesystem to escalate privileges to the host.
  • Mounting the Docker socket inside a container to allow the container to understand the state of the Docker daemon is a relatively common (and dangerous) practice in Docker containers. This gives the host a quick breakout.
  • Docker.sock is a unique socket which acts as the backbone for managing your containers, when you type any docker commands using your docker client, your docker client interacts with this docker.sock and manages your container
  • By default, when the docker command is executed on a host, an API call to the docker daemon is made via a non-networked UNIX socket located at/var/run/docker.sock.
  • This socket file is the main API to control any of the docker containers running on that host.
  • However, many containers and guides require you to expose this socket file as a volume within a container or in some cases, expose it on a TCP port.
  • Docker containers that expose /var/run/docker.sock, locally or remotely, could lead to a full environment take over.
  • Access to /var/run/docker.sock is equivalent to root.
  • Now let’s assume that the attacker somehow landed on the container and got a shell on the container where docker.sock is mounted and in this module we’ll see how an attacker can exploit this vulnerability and take over this container.
  • First, we need to simulate the environment by creating a container with docker.sock mounted on it, for that I use an alpine image. Let’s start an alpine container and name it as sock using the following command:
$ docker run -itd --name sock -v/var/run/docker.sock:/var/run/docker.sock alpine:latest
  • Use the following command to get the shell on the sock container.
$ docker exec -it sock sh
  • Now, we have a container with a docker socket mounted on it , lets see how to exploit it. In the first step, install the docker client inside this container and create another container using this container.
$ apk update
$ apk add -u docker
  • The following command creates a new container which communicates to the underlying container through Unix socket and -v /:/test:ro mount the root directory of the host to the new container and by using sh it returns the shell of the new container.
$ docker -H unix:///var/run/docker.sock run -it -v /:/test:ro-t alpine sh
  • Once we have the shell of the new container, we can go to the /test directory which is the mount point of the root directory of the host.
$ cd /test$ ls
  • The output of ls command will list out all the files and directories present in the root directory of host, which implies that we got a foothold of the host machines filesystem.
Shows you the output of ls command in /test directory
  • When a container runs with — privileged flag, it gives many capabilities to the container. An attacker who is inside the container can take advantage of these capabilities to escape the container and gain a foothold on the host.
  • One of the capabilities provided by — privileged flag is CAP_SYS_MODULE
  • Capability, an attacker who has access to the container, with this capability can escape from the container by installing a kernel module directly to the host’s kernel.
  • We can use it to get a reverse shell on the host where the privileged container is running.
$ docker run -itd --name priv --privileged alpine
$ docker exec -it priv sh
$ apk add -U libcap
$capsh --print
  • Now that we have cap_sys_module capability enabled in our container, we can escape from the container by installing a kernel module directly to the host’s kernel.

Vulnerabilities

  • Most of the developers don’t even know about these vulnerabilities.
  • The top 10 official Docker images with more than 10 million downloads each contain at least 30 vulnerabilities.
  • Among the top 10 most popular free certified docker images,50 percent have known vulnerabilities.
  • 80% of developers don’t test their docker images during development.
  • 50% of developers don’t scan their Docker images for vulnerabilities at all.
  • 20% of the Docker images with vulnerability could have been solved by a simple image rebuild.
  • Most base images have vulnerabilities so we should use very less base images because they can have vulnerabilities.
  • There are many software to scan images so we should scan our docker images before running it.
  • One container for one software/program. If in one container, we install so many software then it will have more vulnerabilities so for fewer vulnerabilities, we should keep one docker container for one software.
  • Before pulling an image from the docker hub, we should make sure that the image is pushed by the genuine publisher and check the authenticity of the image and that image can be tempered.
  • Don’t use the root user for running docker image. Instead of using the root user, create a dedicated user for running docker image.
  • As part of your production pipeline, rebuild your docker files.
  • Scan your Docker images as part of your development workflow and in your CI/CD pipelines. Scan your Docker images in your CI/CD pipelines and as part of your development workflow.
  • Monitor your Docker containers in production by automatically scanning your base images and packages.

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store