All versions of Docker container software contain an unpatched race condition vulnerability that could grant attackers read-write access to the host file system with root privileges.

Designated as CVE-2018-15664, the flaw was published in the U.S. National Vulnerability Database (NVD) last week. The official NVD entry explains that the API endpoints behind “docker cp”, a command used for copying files between the host system and a container machine, are “vulnerable to a symlink-exchange attack with Directory Traversal.”

The flaw was discovered by Aleksa Sarai, a researcher at SUSE, which published exploit scripts in a vulnerability write-up. In his own online report, Sarai says he has created a patch, but the code is still undergoing review.

The specific race condition found in this case is a time of check to time of use condition, or TOCTOU, involving the FollowSymlinkInScope function, whose purpose is to safely resolve a path as if the process took place inside the container. According to Sarai, attackers can exploit the condition if they launch the symlink-exchange attack during a finite, narrow window of time after the path resolution.

“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 up it is opened when creating the archive that is streamed to the client),” Sarai explains. “If an attacker can add a symlink comment to the path after the resolution but before it 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.”

“Unfortunately there isn’t an easy way of fixing this particular brand of TOCTTOU,” Sarai says in the SASE write-up.

NVD analysts assigned CVE-2018-15664 a CVSS v3.0 base score of 8.7 HIGH, but gave it an exploitability score of only 2.2, noting that the attack is of high complexity.

“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,” said Docker in an official statement. “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.”

Sarai, however, contends in his write-up that there are currently no “meaningful protections” to thwart exploitation of this vulnerability “(other than not allowing ‘docker cp’ on running containers – but that only helps with his particular attack through FollowSymlinkInScope). Unless you have restricted the Docker daemon through AppArmor, then it can affect the host filesystem.”

Sarai developed exploit scripts for both read and write access, respectively named run_read.sh and run_write.sh. He says both “include a Docker image that contains a simple binary that does a RENAME_EXCHANGE of a symlink to ‘/’ and an empty directory in a loop, hoping to hit the race condition. In both of the scripts, the user is trying to copy a file to or from a path containing the swapped symlink.”

The run_read.sh is only effective at hitting the race window less than one percent of the time, but attackers could improve their chances of success by either creating a more sophisticated script or simply by trying multiple times. Meanwhile, the other script, run_write.sh, is more effective, and “can overwrite the host filesystem in very few iterations,” Sarai reports.