Critical Vulnerability Found in Docker Copy
Unit 42, the threat intelligence team at Palo Alto Networks, has released research on a proof of concept for what the company claims might be the most severe Docker copy command (“docker cp”) vulnerability yet to be discovered. This new vulnerability allows an attacker to take full root control of the host and any/all containers found within.
The vulnerability, CVE-2019-14271, has already been modified and is awaiting reanalysis, which may result in further changes to the known information. This vulnerability has a base score of 9.8, which makes it critical.
The vulnerability is centered on the docker cp command, which allows the copying of files between host and container as well as from container to container. The command syntax is similar to that of the standard Linux cp command, so:
|
1 |
docker cp container:/source_directory /target_directory |
Where container is the name of the container, source_directory is the directory where the data will be copied from, and target_directory is the directory where the data will be copied to. To achieve the copy, Docker uses the docker-tar helper process, which works by chrooting into the container, archiving the requested files, and passing the resultant tar files to the Docker daemon, which extracts it into the target directory.
It is the chrooting process that allows for the vulnerability discovered by Unit 42, according to Yuval Avrahami, a senior security researcher at Palo Alto Networks. The docker-tar utility “mistakenly loaded libraries, specifically libnss libraries, from the container instead of from the host.”
“The vulnerability was discovered because a user complained in a Docker GitHub issue about a bug he experienced in the docker cp command, not knowing the underlying cause of it was a severe vulnerability.” Avrahami noted, “The user tried to copy files out of a debian:buster-slim container, which is one of the few images that don’t include the libnss libraries. Therefore, when the docker-tar process tried to load the libraries from the container, it failed to find them and crashed.”
This discovery led the Docker maintainers who handled the GitHub issue to realize the cause of the user’s bug was a severe vulnerability, quickly patched it and assigned the CVE.
What Can Developers Do?
When asked what developers and admins should do to protect themselves against the issues, Avrahami said, “First and foremost, make sure you’re not running the vulnerable Docker version. The fix is included in Docker versions 19.03.01 and newer.” Avrahami also added, “Running containers as a non-root user can also mitigate this kind of attack.” Because most breakout vulnerabilities require root access in the container, it is extremely difficult for attackers to achieve such a state if the container runs as a non-root user. Avrahami continues by saying, “In addition to that, never run images from an untrusted source, as they might be malicious and try to take over your host.”
This, of course, leads us to question what is the weakest point with Docker containers: the shared kernel, which “can be challenging to secure,” Avrahami concluded. “As opposed to traditional VMs, containers share the kernel with the host. That means vulnerabilities in the kernel allow containers to compromise the entire host.”
“There are ways to restrict this attack surface though,” he said. “And the best way to do it is by running containers as a non-root user.” Why? Because running containers as a non-root user mitigates a significant portion of exploitable kernel vulnerabilities.
Palo Alto Networks is a sponsor of The New Stack.
Feature image via Pixabay.
