It has been revealed that all Docker versions are vulnerable to a symlink-race attack. A CVE-2018-15664 vulnerability was found by software engineer Aleksa Sarai who submitted the bug to the Docker security team.
“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). If an attacker can add a symlink component 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,” Sarai wrote in a oss-sec mailing list.
Kelly Shortridge, VP of product strategy for the Linux security company Capsule8, explained TOCTOU bugs are time-of-check to time-of-use bugs and are a subset of race condition vulnerability. “TOCTOUs are caused by a mismatch between the conditions when a resource is checked and when a resource is used by a program,” she wrote in a post. “Thus, if attackers can modify a resource between when the program accesses it for its check and when it finally uses it, then they can do things like read or modify data, escalate privileges, or change program behavior. This is bad news for organizations looking to uphold confidentiality and integrity of their data.”
RELATED CONTENT:
The 10 most popular Docker images contain at least 30 vulnerabilities each
Container security requires changes in culture more than changes in technology
While a fix is being worked on, there are currently no known released Docker versions that fix the issue. Sarai is currently working on some of his own Linux kernel patches that hopefully provides some resolution.
“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 wrote.
For now, he added that the “best” option would be to pause the container during use 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,” he explained.
