Docker Vulnerability Gives Arbitrary File Access to Host
A newly disclosed vulnerability in Docker could be exploited by a malicious attacker to escape the container and gain arbitrary read/write file access on the host with root privileges.
Tracked as CVE-2018-15664, the flaw is a time of check to time of use (TOCTOU) bug. Such issues are a subset of race condition vulnerabilities that are caused by a mismatch between the conditions when a resource is checked and when it is used by an application.
Such bugs allow attackers to modify a resource in this interval to read or modify data, escalate privileges, or cause the application to behave differently.
The vulnerability impacts all Docker versions and resides in the FollowSymlinkInScope function, which was meant to resolve paths safely as though they were inside the container, Aleksa Sarai, Senior Software Engineer (Containers), SUSE Linux, explains.
After being resolved, the path “is passed around a bit and then operated on a bit later,” Sarai notes. Thus, if an attacker can add a symlink component to the path in this interval, the symlink path component could end up being resolved on the host as root.
In the case of ‘docker cp’, the path is opened when creating the archive that is streamed to the client and the vulnerability could provide read *and* write access to any path on the host.
“As far as I’m aware there are no meaningful protections against this kind of attack (other than not allowing “docker cp” on running containers — but that only helps with his particular attack through FollowSymlinkInScope),” Sarai notes.
The issue, the engineer explains, can affect the host filesystem, unless the Docker daemon was restricted through AppArmor.
Sarai presented two reproducers of the issue, both of which include a Docker image containing a simple binary that attempts to hit the race condition. One of the scripts, run_read.sh, has a <1% chance of hitting the race condition, while the other, run_write.sh, can overwrite the host filesystem in very few iterations.
“The scripts will ask for sudo permissions, but that is only to be able to create a “flag file” in /. You could modify the scripts to target /etc/shadow instead if you like,” Sarai explains.
A patch has been submitted upstream, but it might take a while before the issue is resolved for users.