Docker Race Condition: CVE-2018-15664
Today, Aleksa Sarai published a Docker vulnerability, CVE-2018-15664, on the oss-sec mailing list. It turns out that a function inside Docker facilitates a TOCTOU bug (more on that below) which could lead to someone malicious inside a container to gain arbitrary read/write file access on the host with root privileges (not just in the container).
Why it’s cool: Time of check to time of use (aka TOCTOU) bugs are a subset of race condition vulnerabilities. TOCTOUs are caused by a mismatch between the conditions when a resource is checked and when a resource is used by a program. For instance, if you began drafting a comment on this article and we disabled comments a second later, a TOCTOU bug would allow you to still post the comment since when comment functionality was checked, comments were allowed.
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.
Digging deeper: The culprit is the FollowSymlinkInScope function, its primary purpose (as opposed to attack purpose) being to safely resolve a specified path (a symlink) as if the process was inside a container — handling paths in a platform-agnostic fashion. However, the resolved path is first passed around and then used later, giving an attacker the opportunity to add a symlink component to the path after resolution but before use — which could give the attacker read and write access to any path on the host using a utility like `docker cp`.
Imagine you are checking a link on a web page to ensure it isn’t going to a malicious domain (like sketchy.click.exe). Once you’ve deemed it safe and go to copy the link on the page, some JavaScript changes the underlying link — leading you to copy a malicious link. This abuses the gap between when you checked the link and when you used the link, just as the attacker in the Docker case is leveraging the gap between when the file path is first processed with `docker cp` and when the file path is used.
Yes, but: The attacker must run their script long enough to hit the race condition, which, according to the initial post, can be as low as a 1% chance. This translates to around 10 seconds, which isn’t that long of a window for detection. Further, reliance on `docker cp` being run on the host is also a limiting factor.
The bottom line: There is no fix for this issue from Docker yet, and there aren’t any other default protections that could really help with this attack beyond banning specific risky utilities within running containers (such as `docker cp`). There are patches in the works, but it could take awhile before a safe version of Docker is available. Thus, for organizations using Docker, you can tap the panic button on this one.
However, Capsule8 customers using Docker can create a policy that ensures `docker cp` doesn’t write to any abnormal locations, meaning no panic button pressing needed.
The Capsule8 Labs team conducts offensive and defensive research to understand the threat landscape for modern infrastructure and to continuously improve Capsule8’s attack coverage.
Kelly Shortridge is currently VP of Product Strategy at Capsule8. In her spare time, she researches applications of behavioral economics to information security, on which she’s spoken at conferences internationally, including Black Hat, AusCERT, Hacktivity, Troopers, and ZeroNights. Most recently, Kelly was the Product Manager for Analytics at SecurityScorecard. Previously, Kelly was the Product Manager for cross-platform detection capabilities at BAE Systems Applied Intelligence as well as co-founder and COO of IperLane, which was acquired. Prior to IperLane, Kelly was an investment banking analyst at Teneo Capital covering the data security and analytics sectors.