A race condition flaw that could be exploited by an attacker to read and write any file on the host system affects any versions of Docker.
Experts found a race condition vulnerability in any versions of Docker, the vulnerability could be exploited by an attacker to read and write any file on the host system.
Technically the flaw, tracked as CVE-2018-15664, is a time-to-check-time-to-use (TOCTOU) flaw caused by changes in a system between the checking of a condition (i.e. authorization check) and the use of the results of that check.
“In Docker through 18.06.1-
The issue resides in the FollowSymlinkInScope function that allows resolving a specified path in a secure way. FollowSymlinkInScope is a wrapper around evalSymlinksInScope that returns an absolute path. This function handles paths in a platform-agnostic manner.
“If you’re not familiar with FollowSymlinkInScope, its job is to take a 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).” reads the advisory published by SUSE. “As you may notice, 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.”
The process leverages the ‘docker cp’ utility to copy content between a container and the local filesystem.
“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). Unless you have restricted the Docker daemon through AppArmor, then it can affect the host filesystem,” continues the advisory.
A possible attack scenario sees an attacker to be active within a container while the host administrator is running docker
Aleksa Sarai, senior software engineer who discovered the issue, proposes as mitigation the modification of the ‘
“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),” said Sarai.
“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).”
The changes impact a core part of Docker, this means that it could be not feasible.
Another mitigation consists of pausing the container when accessing the filesystem, this option could give protection against the more basic attacks that exploit the issue.
At the time of writing, a security patch has been submitted upstream and is currently under review.
Aleksa Sarai also developed two scripts to trigger the vulnerability and get respectively read and write access to the host system.
“Attached is a fairly dumb reproducer which basically does a RENAME_EXCHANGE of a symlink to “/” and an empty directory in a loop, hoping to hit the race condition. Then our “user” attempts to copy a file from the path repeatedly.” explained the expert. “You can call it like this (note that since this requires exploiting a race condition, only a small percentage of the attempts succeed — however if I had made my reproducer a bit more clever about how quickly it does the RENAME_EXCHANGE it could be more likely to hit the race).”
The expert explained that the success rate for his reproducer is 0.6%, that could appear as bad, but using it for a time frame of a dozen of seconds could allow reaching the success.
Thank you
| [adrotate banner=”9″] | [adrotate banner=”12″] |
(SecurityAffairs – Docker, hacking)
[adrotate banner=”5″]
[adrotate banner=”13″]
Share On
