All of the current versions of Docker have a vulnerability that can allow an attacker to get read-write access to any path on the host server. The weakness is the result of a race condition in the Docker software and while there’s a fix in the works, it has not yet been integrated.
The bug is the result of the way that the Docker software handles some symbolic links, which are files that have paths to other directories or files. Researcher Aleksa Sarai discovered that in some situations, an attacker can insert his own symlink into a path during a short time window between the time that the path has been resolved and the time it is operated on. This is a variant of the time of check to time of use (TOCTOU) problem, specifically with the “docker cp” command, which copies files to and from containers.
“The basic premise of this attack is that FollowSymlinkInScope suffers from a fairly fundamental TOCTOU attack. The purpose of FollowSymlinkInScope is to take a given path and safely resolve it as though the process was inside the container. After the full path has been resolved, the resolved path is passed around a bit and then operated on a bit later (in the case of 'docker cp' it is opened when creating the archive that is streamed to the client),” Sarai said in his advisory on the problem.
“If an attacker can add a symlink component to the path after the resolution but beforeit is operated on, then you could end up resolving the symlink path component on the host as root. In the case of 'docker cp' this gives you read and write access to any path on the host.”
Sarai notified the Docker security team about the vulnerability and, after talks with them, the two parties agreed that public disclosure of the issue was legitimate, even without a fix available, in order to make customers aware of the problem. Sarai said researchers were aware that this kind of attack might be possible against Docker for a couple of years. He developed exploit code for the vulnerability and said that a potential attack scenario could come through a cloud platform.
“The most likely case for this particular vector would be a managed cloud which let you (for instance) copy configuration files into a running container or read files from within the container (through "docker cp"),,” Sarai said via email.
“However it should be noted that while this vulnerability only has exploit code for "docker cp", that's because it's the most obvious endpoint for me to exploit. There is a more fundamental issue here -- it's simply not safe to take a path, expand all the symlinks within it, and assume that path is safe to use.”
"Since there has been some suspicion that an attack like this might work for a while they felt it was okay to publish the attack publicly."
Kelly Shortridge, vice pesident of product development at Capsule8, a security firm that specializes in container security, said the Docker vulnerability, while serious, is not necessarily an emergency for most enterprises.
"This TOCTOU bug within Docker allows an attacker to violate data integrity and confidentiality not just within the container, but on the host as well. Beyond banning the docker cp utility on any running containers or using an attack protection product, Docker users leveraging docker cp are vulnerable -- but only for sufficiently motivated attackers who are willing to enter the race against docker cp," she said.
Sarai has submitted a suggested fix for the weakness, which involves pausing containers while the file system is in use.
"The most complete solution to this problem would be to modify chrootarchive so that all of the archive operations occur with the root as the container rootfs (and not the parent directory, which is what causes the vulnerability since the parent is attacker-controlled). Unfortunately, changes to this core piece of Docker are almost impossible (the TarUntar interface has many copies and reimplementations that would all need to be modified to be able to handle a new ‘root’ argument),” Sarai said in the pull request on GitHub.
“So, we instead settle for the next-best option which is to pause the container during our usage of the filesystem. This is far from an ideal solution (you can image some attack scenarios such as shared volume mounts) where this is ineffectual but it does block the most basic attack.”
Docker officials said in a statement that the attack scenario needed to exploit this vulnerability is "rare/unlikely" and that a fix will be merged in the next monthly Docker update.
"Early this week, CVE-2018-15664 was issued to address an issue in Linux, which allows the files in a host to be overridden by a bad actor modifying the symbolic links inside a container during a 'Docker copy' command. This scenario would only be possible if the container was already compromised and a user was using 'docker cp' to replicate the container files and occurred at the same time the copy was being made, a window that is only a few milliseconds. Users can address the issue by manually running 'docker pause' before using 'docker cp' to copy files, and 'docker unpause' after the copy has been made. The issue will be remediated in the next monthly release by inserting a 'docker pause' automatically, which freezes the container when a copy is being made and prevents the container from modifying the data," the company statement says.
“I'm sure that it's something that they will merge as soon as possible, but since there has been some suspicion that an attack like this might work for a while they felt it was okay to publish the attack publicly instead of going through a complete embargo process,” Sarai said.