Under very specific conditions, code running in a Docker container could access files anywhere on a server, according to a new CVE.

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 — is the centre of the vulnerability. In this case, the problem is that a file path that has been checked for safe and authorised copying conditions can be changed between the time of verification and the time of copying, changed to any file, anywhere on the host server.

Kelly Shortridge, VP of Product Strategy at Capsule8, commented: "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,"

Fortunately, this is not a vulnerability that can be exploited remotely. The attacker will need to own a container running on the server and then be able to control the code running in the container. And even within those containers, only the "cp" command is vulnerable. Perhaps due to the difficulty of exploiting the vulnerability is the reason why the researchers and Docker community felt comfortable disclosing the vulnerability before a patch is available. In the hierarchy of things for a CISO to worry about, this vulnerability is deemed a low level concern.

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.

"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, principal security engineer at Kenna Security, Jerry Gamblin commented. “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.

Source: Dark Reading