Unpatched Docker bug allows read-write access to host OS

There are lots of books on tools and techniques to secure software containers, but what happens when someone discovers a basic architectural flaw? And what do you do when there’s no working patch for it?

That’s the situation in the Docker universe this week after Suse developer Aleksa Sarai uncovered a bug in the way that the container framework handles path names.

The bug lies in FollowSymlinkInScope, which resolves file paths given to the Docker container system. Because the function doesn’t immediately use the file path after resolving it, it creates a race condition. An attacker who can interfere with the resolved file path could change it, potentially giving them read-write access to the host OS as a root user.

Containers are a software packages that contain an application and its dependencies. They’re designed to run in exactly the same way, regardless of infrastructure and work by virtualizing an operating system (unlike Virtual Machines that virtualizing hardware). Like Virtual Machines, Containers are not supposed to be able to influence their host container.

This all sounds very serious, and the National Vulnerability Database (NVD) ranks the bug severity as high. Nevertheless, Docker security engineer Justin Cormack had his own context for the flaw, in a statement mailed to Naked Security:

The vulnerability is a rare/unlikely scenario that would require an already compromised container, a copy being made without pausing the container, and a bad actor that knows when that copy is being made.

Someone would have to be using docker cp, a docker command used to copy files between the host OS and the container. The attacker would have to modify the files at the same time the copy was being made. That window is just a few milliseconds long, the company pointed out in its mail.

There’s no working software fix for this problem at the time of writing, according to Sarai, although he has submitted an upstream patch which is now under evaluation. This will automatically pause Docker during usage of the file system.

This sounds like the patch that Docker will use to fix the problem when it issues its next monthly release by automatically inserting a docker pause command. This will freeze the container when a copy is made, meaning that it can’t modify the data.

In the meantime, users can address the issue manually by running the docker pause command before using docker cp to copy files, the company added. They can then run docker unpause after making the copy. They could also disable docker cp, said Sarai, although he suspects there may be other avenues to exploit FollowSymlinkInScope.

In an email to Naked Security, Sarai suggested another mitigation technique, along with a possible way forward for Docker:

It would be good idea to run Docker underneath a restrictive AppArmor profile or with the correct SELinux configuration (which will restrict the scope of bad things that dockerd can do). The next release of Docker has experimental rootless containers support, and I hope in the medium-term people will start using that more often for deployments.

AppArmor is a Linux kernel security module that lets administrators limit what programs can do. SELinux is a set of secure kernel modifications for measures like mandatory access controls.

Sarai reported this privately to Docker a year ago, and the company agreed to the release of the bug information before a patch was available. Sarai told us:

We agreed going through the embargo process would be overkill for a somewhat unlikely attack scenario, not to mention that there was a suspicion this vulnerability existed for quite a few years.