In the toolkit for managing isolated Linux containers with Docker vulnerability (), which under certain circumstances allows access to the host environment from the container when there is an opportunity to run one's own images on the system or access to the running container. The issue appears in all versions of Docker and remains unfixed (proposed but not yet accepted, , implementing the suspension of container operations while performing file system operations).
The vulnerability allows extracting files from the container to any part of the host system's file system when executing the 'docker cp' command. File extraction is performed with root privileges, enabling the reading or writing of any files in the host environment, which is sufficient for gaining control over the host system (for instance, one can overwrite /etc/shadow).
The attack can only be performed at the moment when the administrator executes the 'docker cp' command to copy files to or from the container. Therefore, the attacker needs to somehow convince the Docker administrator of the necessity of performing this operation and predict the path used during the copy. On the other hand, the attack can be carried out, for example, when cloud services provide tools for copying configuration files into the container, built using the 'docker cp' command.
The issue is caused by a flaw in the application of the function , which computes the absolute path in the main file system based on the relative path considering the container's placement. During the execution of the 'docker cp' command, a brief occurs, during which the path has already been verified, but the operation has not yet been executed. Since the copying occurs in the context of the host system's main file system, within that time frame, it is possible to replace the link with another path and initiate data copying to an arbitrary location in the file system outside the container.
As the time window for the manifestation of the race condition is very limited in the prepared When performing copy operations from the container, a successful attack was achieved in less than 1% of cases when cyclically replacing the symbolic link in the path used in the copy operation (the successful attack was carried out after approximately 10 seconds of continuous attempts to copy the file using the 'docker cp' command).
During the copy operation into the container, a repeatable attack can be achieved to overwrite a file in the host system with just a few iterations. This attack is possible because, when copying into the container, the 'chrootarchive' concept is applied, under which the archive extraction process does not occur in the chroot root of the container but rather in the chroot of the parent directory of the target path, controlled by the attacker, without stopping the execution of the container (chroot is used as a marker to exploit a race condition).
Source: opennet.ru
