Security researchers break out of docker containers

Researchers have been able to access the underlying system and execute code from a Docker test environment "Play with Docker" container.
The Docker Play with Docker Playground allows free experiments with Docker containers in a web interface. Each user gets a container with Alpine-Linux, in which he in turn is allowed to start his test container (Docker in Docker). At the end of 2018, security researchers at CyberArk managed to break out of this container environment and execute code on the underlying machine. The concrete vulnerability in Play with Docker has now been closed, but the case shows once again that container technology does not completely seal off.
A container contains only the userland of a Linux distribution and the program to be executed. The kernel is not reloaded in the container - instead, all containers use the kernel of the underlying operating system. The CyberArk researchers managed to put their own module under the kernel and start a shell on the host system. They describe their outbreak in a detailed blog post .
Expedition with standard Linux tool
First, the researchers provided uname -aan overview of their host, tried to mount the underlying file system and failed at a security mechanism. More successful was an analysis with the debugger from debugfs. Reading they moved on the file system of the operating system.
To achieve their goal of running their own code, they looked for a module that uses the kernel function printkand willingly reveals kernel information about it. They found the module ceph.ko for the ceph support and collected the needed details about the kernel. Their goal: to compile their own module, which at least pretends to have been compiled on exactly the same kernel version. Only in this way does the kernel allow the execution at all.
Own module for the kernel
The mission was successful. The researchers built their own module, pushed him the information about the kernel used and let the host run the module. This started a busybox shell that allowed access to the operating system. From the container they could serve the host.
Eviatar Gerzi and his team at CyberArk describe the successful outbreak as "difficult - but not impossible" and summarize the problem: Play with Docker let the container run with elevated rights. Only then was the execution of the own kernel module possible. In November, the researchers informed Play With Docker, in early January, the problem was eliminated.

For the users of Play with Docker the attack should have had no unpleasant consequences - in the playground should be neither precious data nor run productive systems anyway. The platform is primarily for demo purposes and is used in developer conferences for presentations and training. Aside from the concrete and closed loop in Play with Docker, the case for cloud infrastructure operators shows that without further safeguards, containers do not provide 100% isolation of container and host operating system client processes. ( jam ) 

Post a comment