Breaking Out of Docker via RunC

https://www.twistlock.com/labs-blog/breaking-docker-via-runc-explaining-cve-2019-5736/

by zelivans • 7 years ago

116 20 7 years ago

twistlock.com

amerine• 7 years ago

Are those diagrams generated via something or did you create it in an app?

uvuv• 7 years ago

They're created using https://www.draw.io/

awilddocker• 7 years ago

why isn't docker and k8s banned by security teams? these are clearly broken abstractions that would violate most security audits immediately

MotiveMe• 7 years ago

We think of these as deployment abstractions that provide no security value. This is why services like Amazon’s ECS Fargate pair 1 task definition (usually a single container) to a single EC2 host for isolation.

cyphar2• 7 years ago

If you use user namespaces and don't run as host root, they provide a clear security value (unless your alternative is that you use user namespaces in your program, at which point you are making your own container runtime). Docker's (and LXC's) default seccomp profile has blocked something like 95% of kernel 0days since they were added, for instance.

otterley2• 7 years ago

AWS employee here! The relationship is actually one task per EC2 _instance_ (VM isolation), not one task per host. I'm sure you meant the former, but just wanted to clarify for readers.

yutghgh2• 7 years ago

Because the abstractions are good and the implementation gets better over time as with any other software. Obviously truly sensitive data should be handled on separate physical nodes (defense in depth).

praptak• 7 years ago

I am not sure why this got downvoted, it is a valid question which got an informative response.

dasil003• 7 years ago

Because it's a hyperbolic rhetorical question. Security teams don't just unilaterally ban things without context, especially things that provide significant business value. It's about threat modeling and what the risk is in practice for the company and use case in question.

cyphar2• 7 years ago

Allowing your users to run something as root inside a container should violate a security audit. And yes, Docker is almost irresponsible to continue defaulting to root.

But containers themselves should not -- there are plenty of security benefits to using containers. There is no real difference between an LXC container and a runc container besides the fact that Docker defaults to running thing as root and without user namespaces. That is obviously a bad decision, but it's not an indictment of containers as a concept.

helper• 7 years ago

This is a really great exploration of this vulnerability.

It makes me sad that lxc doesn't get more love. LXC has had unprivileged containers as its default for 5+ years now. Its a really solid tool set that has mostly been passed over for lack of marketing.

barbecue_sauce• 7 years ago

The reason Docker gets so much attention is its container image repository infrastructure. I'm sure LXC has something similar, but Docker's is built-in and has almost anything you can think of. (Of course, this presents other security/trust issues).

bboreham• 7 years ago

Need to be careful that Docker and LXC both default to unprivileged, however they use the term to mean different things.

If you say “don’t run your containers as root on the host”, this matches the issue better.

simosx• 7 years ago

A post by Christian Brauner (LXC/LXD developer) on how LXC and LXD are affected. In summary, unprivileged containers (as found in LXD) are not affected.

https://brauner.github.io/2019/02/12/privileged-containers.h...

yutghgh2• 7 years ago

This is very interesting, because most docker break outs I see are exploits in the linux kernel, but this is one of the few in the containerization components themselves (first one I remember in runC).

cpuguy83• 7 years ago

Definitely not the first. There was one with leaking file descriptors which weren't opened with O_CLOEXEC.

Another with ptrace (fixed by making the process non-dumpable).

Breaking Out of Docker via RunC

Related Stories