The vulnerability stems from FollowSymlinkInScope function, allowing a basic time-of-check to time-of-use (TOCTOU) attack that gives read and write access to any file on the host system. The purpose of the FollowSymlinkInScope is to “resolve a specified path in a secure manner by treating the processes as if they were inside the Docker container.” The resolved path is not operated on immediately, meaning that an attack could potentially speculate on the gap and then add a symbolic link path that could resolve on the host with root privileges. The docker cp utility is what allows copying content from Docker containers to the host file system.
There are a few different approaches being proposed when it comes to addressing this vulnerability. Sarai proposed making changes to “chrootarchive.” This would allow archive operations to take place in a secure environment where the root is the container “rootfs.” However, this would involve changing a core piece of Docker, which is not feasible. According to Sarai, “Unfortunately, changes to this core piece of Docker are almost impossible (the TarUntar interface has many copies and re-implementations that would all need to be modified to be able to handle a new ‘root’ argument). Therefore, another approach that has been proposed is to pause the container when using the file system. This would not actually prevent all of the possible attacks. However, it would protect against some of the more basic attacks. A patch to do just this has been submitted upstream and is currently under review.
Sarai provided two different scripts to show off the exploit, one for read and one for write. Sarai explained the scripts are “...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).” Sarai explained that the success rate with this exploit is about .06%, which seems low, but realistically, it would only take about 12 seconds for this exploit to reach success.
Sources: • https://securityaffairs.co/wordpress/86272/hacking/docker-race-condition-flaw.html