Three Docker concepts

Differencies between Dockerfile, Docker Image and Docker Container
21 August 2017   1709

Dockerfile is a file that you create which in turn produces a Docker image when you build it.

A Docker image is created by two actions:

  1. The first action is to create a Dockerfile
  2. The second action is to run some type of build command that uses the Dockerfile

Dockerfile is a text file that Docker reads in from top to bottom. It contains a bunch of instructions which informs Docker HOW the Docker image should get built.

In other worlds, a Dockerfile is a recipe (or blueprint if that helps) for building Docker images, and the act of running a separate build command produces the Docker image from that recipe.

When you run a Docker image, it creates a Docker container.

Let's sum up:

  • Dockerfile is a "recipe" for Docker
  • A Docker image is created by running a Docker command (which uses that Dockerfile)
  • A Docker container is a running instance of a Docker image

Learn more here.

Vulnerability to be Found in Docker

The problem that allows access to the host environment from the container manifests itself in all versions of Docker and remains uncorrected
29 May 2019   191

A vulnerability revealed in the Docker, which allows to get access to the host environment from the container under certain circumstances, only if it is possible to launch own images in the system or when accessing the executable container. The problem manifests itself in all versions of Docker and remains uncorrected.

Vulnerability allows extracting files from the container to an arbitrary part of the host system's FS when executing the "docker cp" command. Extracting files is performed as root, which makes it possible to read or write any files in the host environment, which is enough to gain control over the host system (for example, you can rewrite /etc/shadow).

The attack can be made only when the administrator executes the "docker cp" command to copy files into or out of the container. Thus, an attacker needs to somehow convince the Docker administrator of the need to perform this operation and predict the path used when copying. On the other hand, an attack can be made, for example, when cloud services provide tools to copy configuration files into a container, built using the "docker cp" command.

The problem is caused by a flaw in the application of the FollowSymlinkInScope function, which calculates the absolute path in the main file system based on the relative path that takes into account the placement of the container. During the execution of the "docker cp" command, a short-term race condition occurs in which the path has already been verified, but the operation has not yet been completed. Since the copying is done in the context of the host’s main FS in a specified period of time, you can replace the link to another path and initiate copying data to an arbitrary place in the file system outside the container.

The time window for the manifestation of the race condition is limited in the prepared prototype of the exploit. So, during the copying operations from the container, it was possible to achieve a successful attack in less than 1% of cases with a cyclic replacement of the symbolic link in the path used in the copy operation. A successful attack was made after approximately 10 seconds of attempts to continuously copy the file using the "docker cp".

When performing a copy operation to a container, you can achieve a repeated attack on overwriting a file in the host system in just a few iterations. The possibility of an attack is due to the fact that when copying into a container, the concept of "chrootarchive" is used, according to which the archive.go process retrieves the archive not in the container's chroot root, but in the chroot of the parent directory of the target path controlled by the attacker and does not stop the container (chroot is used as a flag to exploit the race condition).