Hack Allows Play-with-Docker Containers to Escape

Researchers developed a proof-of-concept Docker test environment escape.

Researchers compromised the Docker test platform Play-with-Docker, allowing them to access data and manipulate any running test Docker containers. According to CyberArk researchers who developed the proof-of-concept attack, the proof-of-concept exploit does not affect production Docker instances.

“The team was able to escape the container and remotely execute code directly on the host, which has obvious security implications,” researchers wrote in a Monday-posted technical report.

Play-with-Docker is a free, open-source online playground designed to teach developers how to use containers. Play-with-Docker is supported by Docker, but it was neither created nor is it maintained by the company. The environment simulates the Alpine Linux Virtual Machine in a web browser, enabling users to create and run Docker containers with a variety of configurations.

“Gaining host access from a Linux container should be a challenging, if not impossible, task. “This is not the case in this Play-with-Docker example,” CyberArk wrote. The reason is quite simple: before the fix, Play-with-Docker utilized a privileged container but failed to properly secure it.

On November 6, Docker was notified of the vulnerability. The platform’s developers, identified as Marcos Nils and Jonathan Leibiusky, promised a quick fix the following day. On January 7, a fix for the flaw was implemented.

When asked how many Play-with-Docker instances may have been affected and how many users the platform has, Nils referred all inquiries to Docker media relations. Docker did not respond to inquiries from Threatpost.

CyberArk estimated that up to 200 instances of containers were running on the Play-with-Docker platform it examined. Additionally, it is estimated that the domain receives 100,000 monthly visitors.

Researchers stated that they were able to escape the test container environment by exploiting a virtual machine (VM) vulnerability: “While VMs create a complete copy of the Linux Kernel for every VM instance, containers do not. They utilize the same kernel code, so an adversary escaping the container and gaining access to the host would pose a significant threat. Unfortunately, Play-with-Docker utilized an unsecured privileged container. This indicates that, while difficult, host access was not impossible to obtain.”

In their report, researchers describe the loading of a malicious kernel module into a virtual machine (VM) that escapes and manipulates the kernel of the underlying computer.

“The Linux kernel is a single large code blob. Nimrod Stoler, a cyber security researcher at CyberArk, explained that there are sometimes drivers that are not part of the monolithic code and are instead loaded ad hoc.

For instance, if you connect a USB device and the kernel does not contain the driver, a kernel module will be dynamically loaded into the kernel.

“Kernels only accept modules compiled with the kernel’s source code. “When we wanted to create a module that could communicate with the kernel, we devised a way for the kernel to accept our module,” Stoler explained.

To achieve this, researchers use a module already loaded on the target kernel to assist in the construction of their malicious modules, which ultimately create a reverse shell. A reverse shell is a process initiated on a machine whose input and output are controlled remotely by a remote user on a remote computer.

In this test environment, researchers demonstrated one method for escaping a privileged container. However, they said they are aware of several other methods, which they are not disclosing at this time. CyberArk stated that it is continuing to investigate the potential impact of this Play-with-Docker vulnerability on the production Docker environment.