Home > Tech > Recreating a Docker container breakout with nsjail

Recreating a Docker container breakout with nsjail

Way back in June 2014, Docker published a blog post detailing a security flaw that allowed an attacker to break out of a Docker container and access files on the host file-system. This meant that a user running code within a Docker container could read sensitive files in privileged locations on the host, such as /etc/shadow.

This flaw existed only in Docker versions earlier than 1.0.

A PoC exploit called shocker was made available, and we will use it today, along with nsjail, to demonstrate this vulnerability.

Jen Andre has written a thorough analysis of how this exploit works.

Today’s containers are built using important Linux components such as kernel namespaces, root capabilities, control groups (cgroups), seccomp system-call filtering, pivot_root, and on occasion containers will also use Mandatory Access Control implementations such as AppArmor or SELinux.

General outline:

  1. I recreated this on Ubuntu 18.04 beta (kernel v4.15.0-10)
  2. Download and install nsjail
  3. Download and compile the shocker exploit
    • execute touch /tmp/.dockerinit on your host system (shocker will look for this file)
    • compile shocker: gcc shocker.c -o /tmp/shocker
  4. OPTIONAL: Download amicontained and copy it to /tmp
  5. Launch nsjail
    • sudo nsjail --chroot /tmp -R /bin -R /usr/bin -R /lib64 -R /lib/x86_64-linux-gnu/ --cap CAP_DAC_READ_SEARCH --disable_clone_newuser -- /bin/bash -i
  6. Optionally run /amicontained (from within the nsjail container) and review the output
  7. From within the jailed bash shell, run the exploit: /shocker
  8. Done. You should now see the contents of the host’s /etc/shadow file

Steps 1-4 should be straightforward, but lets talk about the nsjail command:

sudo nsjail \
  --chroot /tmp \
  -R /bin \
  -R /usr/bin \
  -R /lib64 \
  -R /lib/x86_64-linux-gnu \
  --cap CAP_DAC_READ_SEARCH \
  --disable_clone_newuser \
  -- /bin/bash -i
  • --chroot /tmp simply sets the root directory of the container as the host’s /tmp directory
  • The -R switches instruct nsjail to mount the specified directories within the container as read-only. These are necessary for running /bin/bash and utilities such as id inside the container
  • --cap CAP_DAC_READ_SEARCH instructs nsjail to enable this capability for our container, and is crucial for this exploit to work. The documentation for this capability says:

CAP_DAC_READ_SEARCH – Bypass file read permission checks and directory read and execute permission checks; invoke open_by_handle_at(2); use the linkat(2) AT_EMPTY_PATH flag to create a link to a file referred to by a file descriptor.

  • --disable_clone_newuser disables the User namespace. Without disabling the User namespace, the shocker PoC exploit simply won’t work. So what does a User namespace do? see below:
    • For containers whose processes must run as the root user within the container, you can re-map this user to a less-privileged user on the host. The mapped user is assigned a range of UIDs which function within the namespace as normal UIDs from 0 to 65536, but have no privileges on the host machine itself. reference
    • Without container support for the User namespace, it means that if you are root in the container, you are root on the host. The User namespace changes that and allows us to let the container user run as root within the container only, while being mapped to a lower privileged UID on the host.
  • /bin/bash -i – run an interactive bash shell within the container
Advertisement
Categories: Tech
  1. No comments yet.
  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: