This article is more than 1 year old

Update Docker: Fun bug involving file paths and shared libraries turns out to be a security hole

Chroots maneuver

Miscreants can potentially hijack Docker users' computers by tricking them into running malicious containers and waiting for them to kick off a simple copy command – thanks to a critical flaw.

Bug hunters at Palo Alto Networks' Unit 42 say the vulnerability, designated CVE-2019-14271, is the most severe found in Docker since the disclosure of the runc hole in February.

Essentially, this is something developers and other folks using Docker containers just need to be aware of rather than panic over: it can't be exploited remotely over a network, or similar.

Instead, hackers would need to somehow fool a programmer or other Docker user into downloading and running a malicious container, which would then execute code as root on the host machine when they use a docker cp command to copy files out of that container.

Alternatively, a cyber-crim could break into a container and tamper with it to perform the above when a user ran docker cp. The container also needs to be run as a root user, which is the default.

Esoteric, yes. Interesting, also yes, because it involves chroots, shared libraries, and more

Now that the flaw has been patched with Docker 19.03.1, which you should upgrade to, Palo Alto on Wednesday dropped details on how the vulnerability can be exploited.

Roger, cp that

The flaw itself stems from the way Docker runs the cp copy command. When copying files out of a container, it runs a process called docker-tar on the host system and in a chroot in the container. The chroot ensures the operation doesn't unexpectedly overwrite data on the host via a symlink.

"Chrooting is mostly done to avoid symlinks issues, which can occur when a host process tries to access files on a container," explained Unit 42 senior researcher Yuval Avrahami. "If one of those files is a symlink, it might inadvertently be resolved under the host root."

However, docker-tar loads shared libnss_*.so libraries, and the chroot causes it to load from the container rather than from the host system as expected. Thus, a malicious container could include a specially crafted libnss_*.so library that is loaded and executed by docker-tar, which runs with root privileges on the host. And bingo, the container can now run stuff on the host machine, such as install spyware or crypto-mining software.


Just Docker room talk: Container upstart's enterprise wing sold to Mirantis, CEO out, Swarm support faces ax


"Normally, libraries would be loaded from the host file system, but since docker-tar chroots to the container, it loads the libraries from the container file system," said Avrahami. "That means docker-tar will load and execute code originating and controlled by the container.

"To clarify, aside from being chrooted to the container filesystem, docker-tar isn’t containerized. It runs in the host namespaces, with all root capabilities and not limited by cgroups or seccomp. Therefore, by injecting code into docker-tar, a malicious container gains full root access to the host."

To close the vulnerability, Unit 42 says Docker's latest update causes it to load its own version of libnss rather than the one from the container. This prevents untrusted libraries from being used by the docker-tar process.

While devs and admins can protect themselves from this specific attack by updating to the latest version of Docker, Avrahami also advises folks to prevent similar attacks by never firing up untrusted containers and not running containers as a root user.

"When root is not strictly needed, I highly recommend running containers as a non-root user," the researcher explained. "This further increases their security and prevents attackers from exploiting many of the flaws that may be found in container engines or the kernel." ®

More about

More about

More about


Send us news

Other stories you might like