In the toolkit for managing isolated Linux containers Docker vulnerability (), which, under certain circumstances, allows you to access the host environment from the container if you can run your images in the system or when accessing the running container. The problem appears in all versions of Docker and remains unfixed (proposed, but not accepted yet, , which implements the suspension of the container for the duration of operations with the file system).
The vulnerability allows extracting files from a 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 of the host system (for example, you can rewrite /etc/shadow).
The attack can only be carried out when the administrator executes the "docker cp" command to copy files to or from the container. Thus, the attacker needs to somehow convince the Docker administrator 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 a means to copy configuration files to a container, built using the “docker cp” command.
The problem is caused by a flaw in the application of the function , which calculates the absolute path in the main FS based on the relative path, taking into account the location of the container. There is a momentary error while executing the "docker cp" command. , in which the path has already been checked, but the operation has not yet been completed. Since copying is performed in the context of the main FS of the host system, within the specified period of time, you can change the link to another path and initiate copying of data to an arbitrary location in the file system outside the container.
Since the time window for the manifestation of a race condition is severely limited in the prepared when performing copy operations from a container, it was possible to achieve a successful attack in less than 1% of cases when cyclic substitution of a symbolic link in the path used in the copy operation (a successful attack was carried out after about 10 seconds of attempts to continuously copy the file in a cycle with the “docker cp” command).
By performing a copy-to-container operation, it is possible to achieve a repeatable file overwrite attack on the host system in just a few iterations. The possibility of an attack is due to the fact that when copying to a container, the “chrootarchive” concept is used, according to which the archive.go process extracts the archive not into the chroot of the container root, but into the chroot of the parent directory of the target path controlled by the attacker and does not stop the execution of the container. (chroot is used as a flag to exploit the race condition).
Source: opennet.ru
