Researchers hacked the Docker test platform called Play-with-Docker, allowing them to access data and manipulate any test Docker containers running on the host system. The proof-of-concept hack does not impact production Docker instances, according to CyberArk researchers that developed the proof-of-concept attack.
“The team was able to escape the container and run code remotely right on the host, which has obvious security implications,” wrote researchers in a technical write-up posted Monday.
Play-with-Docker is an open source free in-browser online playground designed to help developers learn how to use containers. While Play-with-Docker has the support of Docker, it was not created by nor is it maintained by the firm. The environment approximates having the Alpine Linux Virtual Machine in browser, allowing users to build and run Docker containers in various configurations.
“Gaining host access from a Linux container should be a very difficult task, if not impossible. In this Play-with-Docker example, that’s not the case,” CyberArk wrote. “The reason is quite simple: Play-with-Docker uses a privileged container, and prior to the fix, failed to secure it properly.”
Play-with-Docker was notified of the vulnerability on November 6. The following day the developers of the platform, identified as Marcos Nils and Jonathan Leibiusky, promised a quick fix. On January 7 the bug was patched.
When asked how many instances of Play-with-Docker may have been impacted and how many users of the platform there are, Nils directed questions to Docker media relations. Docker did not respond to Threatpost’s inquiries.
CyberArk estimated there were as many as 200 instances of containers running on the Play-with-Docker platform it analyzed. It also estimates the domain receives 100,000 monthly site visitors.
Researchers said they were able to escape the test container environment by focusing on a virtual machine weakness (VM): “While VMs create a full copy of a Linux Kernel for every single VM instance, containers don’t. They use the same kernel code, which means that an adversary escaping the container and gaining host access would be a huge problem. Unfortunately, Play-with-Docker used a privileged container that they failed to secure. This means that host access, while difficult, was not impossible to attain.”
In their report, researchers detail loading a malicious kernel module into VM that escapes and manipulates the underlying computer, or kernel.
“The Linux kernel is one big chunk of code. Sometimes there are drivers that are not part of the monolithic code and are instead loaded on demand,” explained Nimrod Stoler, a cyber security researcher with CyberArk.
For example, if you plug in a USB device and the kernel doesn’t have the driver, a kernel module will load dynamically into the kernel.
“Kernels only accept modules of their own – compiled with the kernel code. So when we wanted to create a module to talk to the kernel, we developed a way for the underlying kernel to accept our module,” Stoler said.
To accomplish this, researchers use a module already loaded on the target kernel to help build their own malicious modules that ultimately creates a reverse shell. A reverse shell is a process started on a machine, with its input and output being controlled by a remote user from a remote computer.
While researchers demonstrated one way to escape a privileged container in this test environment, they said they are aware of several other ways, which they are not releasing details of at this time. CyberArk said it is continuing its research to determine what impact, if any, this weakness in Play-with-Docker may have with the production Docker environment.
