Deep-Seated Container Vulnerability Found, Corrected

A vulnerability in container operations has been brought to light by Docker and other parties and illustrates why lack of multiple years of experience with containers makes some implementers cautious. A command to execute the RunC part of the Linux kernel under rare but exploitable circumstances can result in a container process getting a chance to inspect file descriptors on the host.

In the hands of the wrong party, such information available to malevolent code hidden in the container could result in file descriptors on the host system being disclosed or the container itself escaping from its assigned memory space into the host's operations. Since many containers run under the root privilege, such an escape would unleash an intruder into the heart of the host server, a circumstance those running containers in production hope at all costs to avoid.

The vulnerability affects Docker, which issued a patch on Jan. 10. But bloggers at Aqua Security, a firm established by security veterans of Intel, CA Technologies and Imperva, said the vulnerability would be found in non-Docker container systems that make use of the Open Containers Initiative's standard RunC code.

The distributors of Arch, a minimal Linux product, rated the vulnerability as "high" on this listing. Cloud Foundry, the open source development platform, listed it as "medium" for its members because it had already included protections against this type of vulnerability inside its Garden container system.

To see why your future almost certainly includes container operations, read Bain: Is Container Use Optional? Probably Not.

The vulnerability was most likely to be implemented with the use of ptrace, or Process Trace, a Linux system call that allows one process to control another, warned bloggers at Red Hat and CoreOS. Under certain circumstances, when RunC implements ptrace, "This allows the main processes of the container...to gain access to file-descriptors of these new processes during the initialization and lead to container escapes…" said Alex Crawford at CoreOS in a blog posted Jan. 10.

The vulnerability was given the designation CVE-2016-9962 on the list of Common Vulnerabilities and Exposures maintained by the Department of Homeland Security. The designation, however, is linked to little information about the defect. Bugzilla labeled it bug 1012568.

Container experts at Aqua Security, a firm formed from security specialists at Intel, CA Technologies and Imperva (previously known as Scalock), said the vulnerability doesn't affect just Docker users but any user of RunC, as established by the Open Container Initiative.

In a blog posted Jan. 17 entitled CVE-2016-9962: Run Container, Run! Aqua Security senior researcher Sagie Dulce said the window for mischief "is very small." It occurs when a RunC initialization process executes a command inside the container when the container also has access to the RunC process on the host.

"This window could enable a container, for example, to list file descriptors on the host process, which can then lead it to the host’s file system. Because many containers run as root, this indeed has serious implications," he wrote in the blog.

The exposure is more pernicious because it occurs so close to many other operations on the host. If a container administrator thinks something might be wrong with a container, he might run a Linux shell inside the container to understand the issue. "If that container is malicious, the process of running that shell could enable it to escape to the host," he warned.

After such an escape, there would be little sign that anything was amiss. "The container can return to normal behavior and you can go back to doing whatever it is your were doing… but oblivious to the exploit that just took place," he said.

Software engineers Aleksa Sarai at SUSE working with Tonis Tiigi at Docker discovered and documented  the bug and came up with the patch.

The fact that those most concerned about secure operations made the find is unlikely to totally settle the remaining doubts about container operations. IT managers are responsible for the privacy and security of information that may one day be flowing through containerized systems presumed secure but experiencing a not yet disclosed vulnerability. It will take many more years of secure operations before containers, running under a shared operating system and in a shared memory space with only logical boundaries between them, will be 100% trusted.