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

Source link

Register at Binance