A lot of today’s services that run on servers do so in containers, either in small setups that use Docker, for example, or in Kubernetes clusters for larger deployments. By design, containers encapsulate an application, so threads in a container can’t modify anything on the host computer that is not specifically attached to the container. Also, threads running in containers can’t see what’s going on outside or what is going on in other containers. So how can programs break out of containers? The answer: If they are able to gain root rights.
The big question then is, how programs running inside a container can obtain root rights. So far, I didn’t pay a lot of attention to this until the “Dirty Pipe” kernel bug was disclosed. When reading about the issue, it became immediately apparent to me how this could be used to break out of a container. Have a look at this link that I googled later for some details.
So how could an attack vector that uses such a vulnerability look like? Let’s say there’s a web server running in the container and a PHP application that can be tricked into opening a reverse shell to the attacker. There seem to be lots of such vulnerabilities around to achieve this on unpatched systems. By itself, getting a reverse shell would ‘only’ compromise a single container and the data that is accessible for it. Bad enough. An attacker could then perhaps try to move laterally, as containers usually talk to other containers and try to exploit security issues of the software in other containers from the inside.
But with a reverse shell and a “Dirty Pipe” chain, the attacker could gain root and break out of the container environment into the host. So long story short: When running containers, have a close look at kernel vulnerabilities, and patch the host system immediately.