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   400

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).

Mirantis to Acquire Docker Enterprise Platform

After the sale of the enterprise part, Docker Inc will continue to exist in the form of an independent company and will be focused around the Docker Hub
14 November 2019   81

Mirantis, an OpenStack and Kubernetes-based cloud solution, has bought part of the Docker Enterprise platform business from Docker Inc (a commercial version of the enterprise toolkit and Docker engine, which also includes the Docker Enterprise Container Engine, Docker Trusted Registry, and Docker Universal Control Plane). After the sepation of the business, Docker Inc will continue to exist in the form of an independent company and will focus its activities around the Docker Hub catalog and the integrated development environment for microservices and Docker Desktop applications launched in containers.

Financial terms of the transaction were not disclosed. The team of developers, managers and support specialists who developed the Docker Enterprise platform will move to Mirantis. Mirantis will also receive contracts with 750 customers. The development of the open-source Docker project will continue with the participation of both companies, who together will continue to work on the Docker core and will ensure compatibility and portability in their products.