Docker Vulnerability Opens Servers to Container Code

A recently discovered vulnerability in the Docker container platform could allow an attacker to gain access to files used by other containers and the host server itself. And, in an unusual progression of events, the vulnerability and exploits have been disclosed before patches are available.

The vulnerability, designated CVE-2018-15664, was discovered by researcher Aleka Sarai. A flaw in the Docker "cp" command, which provides a method for copying a file from the host system to a container, could give an attacker arbitrary read-write access to the host file system with root privileges.

A "race condition" — specifically a "time of check to time of use" (TOCTOU) bug — lies at the heart of the vulnerability. In this case, the problem is that a file path that has been checked for safe and authorized copying conditions can be changed between the time of verification and the time of copying, changed to any file, anywhere on the host server.

"It's not just a violation of integrity and confidentiality. If the attacker successfully exploits this bug, not only can they get read and write access on data within the container, it actually opens the host itself to integrity and confidentiality violations as if it were in the container," says Kelly Shortridge, vice president of product strategy at Capsule8.

Fortunately, this is not a vulnerability that can be remotely exploited. "You'd have to own a container running on the server and then be able to control the code running in the container," explains Jerry Gamblin, principal security engineer at Kenna Security. And even within those containers, only the "cp" command is vulnerable.

That difficulty in exploiting the vulnerability is likely why the researchers and Docker community felt comfortable disclosing the vulnerability before a patch is available.

"The thing that grabbed me and was the talk of the security community yesterday is that they talked to people and allowed them to release the bug and the scripts before the patch was out, which to me indicates that it is probably low risk to most people," Gamblin says.

Until that patch is released, a brute-force fix may be the only remediation option.

"Because Docker 'cp' doesn't seem to be used in many automated processes, organizations for now can probably just block that utility until there's a fix out," Shortridge says.

In the hierarchy of things for a CISO to worry about, this vulnerability should be at a low level, both Gamblin and Shortridge say. Unfortunately, each also says there are factors that will keep it a low-level concern for some time to come.

"People should also be aware that it appears that Kubernetes is able to use Docker 'cp' as well," says Shortridge, which makes it possible for orchestration playbooks to include the vulnerability. And the vulnerability patch, when it arrives, may not make the problem go away.

The common practice of simply pulling an existing container from a Docker pool and using it means that, if the individual maintaining the container doesn't update it, developers pulling the vulnerable container might never know they are deploying a flawed container, Gamblin says.

Still, he points out, this is a weakness, but not a structural weakness. Shortridge agrees, saying this is a cause for caution, but not at all a reason for panic.

Related content: