
Full Docker Breakout Exploit - uvuv
https://unit42.paloaltonetworks.com/docker-patched-the-most-severe-copy-vulnerability-to-date-with-cve-2019-14271/
======
uvuv
A PoC for CVE-2019-14271, which can be exploited by a malicious container to
gain root code execution on the host.

------
yrro
> The fix included patching the init function of docker-tar to call arbitrary
> functions from the problematic Go packages. This forced docker-tar to load
> the libnss libraries before chrooting to the container, and thus from the
> host filesystem.

This seems like a band aid, not a proper fix. docker-tar is still run,
chrooted into the untrusted container root directory, but in the host's
namespace (i.e., ubcontained). As we all know, chroot on Linux is not a
security barrier!

I think it would be better to run one docker-tar entirely inside the
container, writing to a socket; with another docker-tar on the host reading
from the other end of the socket.

Taking a step back though I have to ask why 'docker cp' has to execute
anything at all. I would not expect that copying files would need to do
anything other than open files within the container and read them. I suppose
this would only be possible if the open syscall had a way to prevent symlinks
being followed (O_NOFOLLOW is not sufficient because it only applies to the
final file in the path, not any parent directories).

~~~
uvuv
Hi, OP here. You're correct on the symlink point, they're the reason chrooting
is needed, as they caused several vulnerabilities in Docker and Podman cp in
the past. The good news is that there is a new syscall designed to solve that
exact problem, openat2(), which you'll be able use to restrict path resolution
when opening files
([https://lwn.net/Articles/796868/](https://lwn.net/Articles/796868/)). It
will make helper processes and chrooting to the container redundant.

Running helper processes entirely in the container is actually quite
problematic, since they will be visible to proceses in the container that
could try to affect their output. This solution though is used in Kubernetes,
and it resulted in 4 vulnerabilities in the last year. Ariel Zelivansky and I
just gave a talk on the security of the cp command in KubeCon, you can check
out the slides here
([https://kccncna19.sched.com/event/d229f00f143036f7c488144e60...](https://kccncna19.sched.com/event/d229f00f143036f7c488144e604f91ea?iframe=yes&w=100%&sidebar=yes&bg=no#))
for more information.

As for the fix, I'm pretty sure newer Golang versions stopped dynamiclly
loading libraries at runtime, which is nice. I Should have included that in
the post but forgot.

~~~
yrro
Wouldn't you have the option of running the helper process within the mount
namespace but not the process namespace of the container?

Regardless, openat2 looks like a much better solution. I hope it's backported
to LTS distros so I can start relying on it before 2035...

~~~
uvuv
That's an option, an actually what LXD does. It's better then just chrooting,
though in the case of this vulnerability even if docker-tar entered the mount
NS, the exploit will still work.

------
smittywerben
I was never under the impression that docker was secure or even claimed to
have security (do they?). I feel this is a common belief.

For me Docker felt halfway between VirtualBox and Parallels. And VirtualBox
had shared folder breakout exploits as far back as 2007.

[https://www.coresecurity.com/content/advisory-
vmware](https://www.coresecurity.com/content/advisory-vmware)

