Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

CVE-2019-5736: runc container breakout

seclists.org

Post reply on HN
Print view View original

81–90 of 102 posts

Re: CVE-2019-5736: runc container breakout

#81

Post by SAI_Peregrinus »

wicket wrote: post #58

> However, it is blocked through correct use of user namespaces (where the host root is not mapped into the container's user namespace). In other words, this won't affect anyone who understands the implications of running a process as root. Unfortunately, the sad truth is that most people I've come across who have "lots of experience" with implementing Docker containers, do not even understand the basics of how they…

I've done pretty much nothing with Docker (we use it at work to ensure consistent builds, all I do involving is run the shell script that uses it to build the code.)

I'd say Docker is a rather spiffed-up version of BSD chroot jails, with a repository and more than just filesystem isolation. Jails for all the things.

Probably just as wrong as the "lightweight virtualization" but I found it interesting that people claiming to have experience with Docker would immediately compare it with virtualization instead of jails. Not enough BSD?

Re: CVE-2019-5736: runc container breakout

#82

Post by megous »

pizlonator wrote: post #32
megous wrote: post #16

Earlier quoted context omitted.

By your guess each new Linux release would have about 5000 new RCEs. So that's 25000-30000 new RCEs over the last year alone.

I wasn’t being completely serious. But taking the joke further, are you counting each release’s lines of code towards the RCEs or only new/modified code? If you’re counting all vise then you’re double counting RCEs. I wouldn’t double count.

New lines only. It's approx half a mil. new lines of code in each recent release.

Re: CVE-2019-5736: runc container breakout

#83

Post by bpye »

miguelmota wrote: post #13

For better isolation check out KataContainers: https://github.com/kata-containers/runtime It's a drop-in replacement for runc. With KataContainers it runs docker containers in a lightweight VM so you get all the security benefits of a VM. The downside is slightly slower container start up times and might not work in nested virtualized environments.

gVisor is also pretty neat, they say KVM support is experiemental though: https://github.com/google/gvisor

gVisor is used behind Go 1.11 on App Engine so Google must be fairly confident that it's a sufficient security boundary though I'm fairly sure they don't use the public KVM isolation so YMMV.

Re: CVE-2019-5736: runc container breakout

#84

Post by ajross »

int_19h wrote: post #80
ajross wrote: post #23

Earlier quoted context omitted.

Jails are virtually identical technology to Linux containers from a security point of view. They've had holes before and they likely will again, and a breakout like this (seems like the root cause here is a writable file descriptor to the host binary) can absolutely compromise the host system. The upthread recommendation was using hardware VM technology, which is a fundamentally different isolation model from what so…

My understanding is that jails were designed as a security boundary from the get go, unlike containers. Wouldn't that result in code that's less likely to be exploitable?

FWIW, "containers" aren't a thing. Namespaces, cgroups et. al. certainly were designed with security in mind, as was docker/runc.

Look, this isn't about whether jails are secure containers or not. I'm sure they're great. It's that responding to "if you want more isolation, try hardware virtualization" with "FreeBSD is just better because 19 years!" is not really enaging with the argument as framed.

Re: CVE-2019-5736: runc container breakout

#85

Post by geofft »

nicoburns wrote: post #79
wicket wrote: post #69

Earlier quoted context omitted.

> I think it's subtler than that. It is mostly safe to run a process as "root" because in theory the ways that root access can be exercised is highly sandbox by the use of various namespaces, as well as things like capability restrictions (you generally don't have CAP_SYS_ADMIN or a few others), limited syscall attack surface (you generally have a syscall allowlist via seccomp-bpf), etc. Yes, it's wrong to not unders…

I believe there was work on non-root container host processes going on at some point? Did that ever get to a usable state?

Rootless containers using user namespaces was merged into runc in March 2017: https://github.com/opencontainers/runc/pull/774

A week ago Docker gained support for running dockerd as non-root: https://github.com/moby/moby/pull/38050

And there is this project for running Kubernetes as non-root: https://github.com/rootless-containers/usernetes

Re: CVE-2019-5736: runc container breakout

#86

Post by cyphar »

geofft wrote: post #64
wicket wrote: post #58

> However, it is blocked through correct use of user namespaces (where the host root is not mapped into the container's user namespace). In other words, this won't affect anyone who understands the implications of running a process as root. Unfortunately, the sad truth is that most people I've come across who have "lots of experience" with implementing Docker containers, do not even understand the basics of how they…

I think it's subtler than that. It is mostly safe to run a contained process as "root" because in theory the ways that root access can be exercised is highly sandbox by the use of various namespaces, as well as things like capability restrictions (you generally don't have CAP_SYS_ADMIN or a few others), limited syscall attack surface (you generally have a syscall allowlist via seccomp-bpf), etc. Yes, it's wrong to no…

> I think it's subtler than that. It is mostly safe to run a contained process as "root" because in theory the ways that root access can be exercised is highly sandbox by the use of various namespaces, as well as things like capability restrictions (you generally don't have CAP_SYS_ADMIN or a few others), limited syscall attack surface (you generally have a syscall allowlist via seccomp-bpf), etc.

I disagree. It is definitely "safer" than running as root on the host -- but that shouldn't be the baseline. Honestly, I would argue that not using user namespaces (or non-root inside the container) is basically negligence at this point. Yes, it's annoying to do it with Docker, but other runtimes have solved this problem.

LXC actually explicitly states that privileged (non-userns) containers are fundamentally unsafe and I agree. When you look at the wide array of ns_capable and other userns checks that protect against all sorts of attacks, you really start to not trust anything that doesn't use user namespaces. Kernel developers assume that container runtimes are using user namespaces if they are trying to secure something.

Additionally, yes capabilities help. But you still have traditional Unix DAC issues (which is what is leveraged here).

> and this vulnerability is notable precisely because it's one of the rare ways to exercise that root privilege outside the container.

I would argue there's several very foundational security problems (which I'm trying to fix) that are made significantly worse by running a container process as root. Please don't do it.

Re: CVE-2019-5736: runc container breakout

#87

Post by cyphar »

nicoburns wrote: post #79
wicket wrote: post #69

Earlier quoted context omitted.

> I think it's subtler than that. It is mostly safe to run a process as "root" because in theory the ways that root access can be exercised is highly sandbox by the use of various namespaces, as well as things like capability restrictions (you generally don't have CAP_SYS_ADMIN or a few others), limited syscall attack surface (you generally have a syscall allowlist via seccomp-bpf), etc. Yes, it's wrong to not unders…

I believe there was work on non-root container host processes going on at some point? Did that ever get to a usable state?

Yes, it's in a usable state. Docker just merged a PR that allows you to run it rootless[1]. Props to Akihiro for bringing this one over the line, I didn't think it'd be possible three years ago.

[1]: https://github.com/moby/moby/commit/ec87479b7e2bf6f1b5bcc657...

Re: CVE-2019-5736: runc container breakout

#88

Post by cyphar »

pizlonator wrote: post #10

Yikes that's a big patch! Just on a meta-level, security vulnerabilities fixed with big patches are usually the least fun. Also, I would bet that freshly written C code has about 1 RCE bug every 100 LoC. This patch has 236 LoCs so probably about 2.36 RCE's.

The version of the patch pushed to master is significantly simpler[1], and the context in which the code runs is so trivial that standard C vulnerabilities are unlikely to happen (meaning that we are doing IO to a memfd and if any errors happen we abort the process -- and immediately after the C code is set up we either execve or we boot the Go runtime which scrubs over all memory anyway).

My first attempts at this patch used Go code but it wasn't possible to protect against all cases. Doing it in C was the only way to do it.

[1]: https://github.com/opencontainers/runc/commit/0a8e4117e7f715...

Re: CVE-2019-5736: runc container breakout

#89

Post by tristanz »

NathanKP wrote: post #28

Amazon employee here: we have released a security bulletin covering how to update to the latest patched Docker on Amazon Linux, Amazon ECS, Amazon EKS, AWS Fargate, AWS IoT Greengrass, AWS Batch, AWS Elastic Beanstalk, AWS Cloud9, AWS SageMaker, AWS RoboMaker, and AWS Deep Learning AMI. Please check out the bulletin and update if you are using one of these services. https://aws.amazon.com/security/security-bulletins/…

As far as I understand, EKS doesn't support PodSecurityPolicy yet so any user that can launch a pod can trivially root the host via host mounts already. This surprisingly isn't clearly documented.
Post reply on HN