Contain yourself, Docker: Race-condition bug puts host machines at risk… sometimes, ish

May 29, 2019

Contain yourself, Docker: Race-condition bug puts host machines at risk… sometimes, ish

Institute For Ethical Hacking Course and Ethical Hacking Training in Pune – India

Extreme Hacking | Sadik Shaikh | Cyber Suraksha Abhiyan

Credits: The Register

A vulnerability in all versions of Docker can be potentially exploited by miscreants to escape containers’ security protections, and read and write data on host machines, possibly leading to code execution.

This is according to senior SUSE software engineer Aleksa Sarai, who said the flaw is a race condition bug in which a file path is changed after it has been checked as valid, and, crucially, before it is used.

The flaw, designated CVE-2018-15664, can be, in certain circumstances, abused to read and write arbitrary files on the host with root permissions from within a container, Sarai explained on Tuesday. This is possible provided there are no file system restrictions on the Docker daemon, such as those imposed by AppArmor.

And the most likeliest attack scenario requires a miscreant to be active within a container when a host administrator runs docker cp to copy data in or out of the container, at which point the attacker strikes to potentially alter the underlying host file system.

So, not really an emergency, and more of an annoyance at this stage.

Behind the scenes

At the heart of the vulnerability is a function called FollowSymlinkInScope, which is used by Docker to resolve file paths. What Sarai found was that, in the case of docker cp, the paths could be modified using a symlink within the container to instead alter data on the host file system.

“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,” Sarai told The Register. “An example might be some cloud management service which allows users to copy configuration files into containers (or to read files from within a container.)”

Though Sarai’s disclosure focuses on docker cp, he noted that the root cause of the issue goes much deeper.

“The core flaw here is that there is an assumption that a path inside a container can be safely cleaned up to be as-is by a privileged process,” he explained, “and any Docker endpoint which touches FollowSymlinkInScope might be vulnerable.”

To demonstrate the vulnerability in action, Sarai crafted a set of proof-of-concept scripts that show how the flaw can potentially be exploited from within a container to change files on the host machine. Sarai notified Docker’s security team privately of the hole ahead of this week’s public disclosure.

The PoC only works around one per cent of the time (race conditions are notoriously hard to recreate), but with repeated attempts, Sarai said, it can be reliably performed in around 10 seconds, most of the time.

Thus far, the bug hunter noted, there is no official fix available, and Docker has not said when a patch may be out. The company declined to comment. Sarai went public with the bug after the Docker security team agreed it would be better to alert customers while a patch is developed.

“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 in his suggested solution.

“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).

“So, we instead settle for the next-best option which is to pause the container during our usage 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.”

Thus, so far, the proposed fix would be to pause containers during file operations, though that is unsatisfactory. Another short-term mitigation would be to disable docker cp. Sarai plans to continue to work on fixing the bug from within Linux.

“In an attempt to come up with a better solution for this problem, I’ve been working on some Linux kernel patches which add the ability to safely resolve paths from within a rootfs,” the engineer added. “But they are still being reviewed and it will take a while for userspace to be able to take advantage of the new interfaces.”