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

21–30 of 102 posts

Re: CVE-2019-5736: runc container breakout

#21

Post by peterwwillis »

justanother- wrote: post #17
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.

Alternative idea: throw away docker and katacontainers and move to freebsd, where jails were introduced on 14 Mar 2000 (no, seriously, superior technology exists for 19 years - stable, time proven, working). Some more info: https://www.freebsd.org/doc/handbook/jails.html And for quick start: https://github.com/iocage/iocage

The major use case for Docker is really as a massively simplified package manager and an entrypoint for distributed applictions. Other features, like quicker runtime than VMs and system isolation, are just icing on the cake.

It took a massive marketing campaign to get people to use Docker and realize it made their life easier, so something like iocage would need the same push. (Also, nobody wants to start adopting additional OSes unless absolutely necessary)

Re: CVE-2019-5736: runc container breakout

#22

Post by v_lisivka »

justanother- wrote: post #17
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.

Alternative idea: throw away docker and katacontainers and move to freebsd, where jails were introduced on 14 Mar 2000 (no, seriously, superior technology exists for 19 years - stable, time proven, working). Some more info: https://www.freebsd.org/doc/handbook/jails.html And for quick start: https://github.com/iocage/iocage

Linux VServer project started in 2003: http://linux-vserver.org/ChangeLog-1.2 . We used it in production more than 10 years ago at multi-terabyte site (Bazaarvoice).

Re: CVE-2019-5736: runc container breakout

#23

Post by ajross »

justanother- wrote: post #17
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.

Alternative idea: throw away docker and katacontainers and move to freebsd, where jails were introduced on 14 Mar 2000 (no, seriously, superior technology exists for 19 years - stable, time proven, working). Some more info: https://www.freebsd.org/doc/handbook/jails.html And for quick start: https://github.com/iocage/iocage

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 software can provide and (at least in theory) makes that kind of exploit impossible. And while there are tradeoffs with everything, for you to throw that argument out due to personal platform loyalty is really, really bad advice.

Re: CVE-2019-5736: runc container breakout

#24

Post by justincormack »

darren0 wrote: post #9

The best fix is to upgrade to 18.09.2. For those that can't do that immediately, backported versions of runc for Docker releases going back to 1.12.6 are available from Rancher at https://github.com/rancher/runc-cve . But please only do that as a temporary workaround until you can properly upgrade to 18.09.2. Please patch if you don't 100% trust all users on your host.

We also released Docker 18.06.2 with the fix, as a lot of Kubernetes users are on this release.

Re: CVE-2019-5736: runc container breakout

#25

Post by justanother- »

jeswin wrote: post #19
justanother- wrote: post #17

Earlier quoted context omitted.

Alternative idea: throw away docker and katacontainers and move to freebsd, where jails were introduced on 14 Mar 2000 (no, seriously, superior technology exists for 19 years - stable, time proven, working). Some more info: https://www.freebsd.org/doc/handbook/jails.html And for quick start: https://github.com/iocage/iocage

There have been vulnerabilities in jails previously. Also, Linux gets far more attention from exploit researchers because of wider adoption - so the number of incidents isn't a good metric. Kata has hardware isolation, so will be safer. If I have misunderstood jails and it's immune to kernel exploits please do correct me.

Sorry, I am not going into endless debates. It is waste of my time. Check documentation, read about it and technology is here for 19 years. I dont care what anyone useses. I have just stated what the most reliable technology for compartmentization is. Docker and kata are in IT time since yesterday and there are lots of dragons still hiding. Same goes for integration with ZFS (part of freebsd since 6 April 2007).

Re: CVE-2019-5736: runc container breakout

#26

Post by spydum »

achillean wrote: post #18

There are nearly 4,000 exposed Docker daemons: https://www.shodan.io/report/ol761bRb

If your dockerd is exposed without something like mutual TLS auth, RCE is a feature! Some little container breakout is irrelevant (I’m sure you know, but others might be confused)

Re: CVE-2019-5736: runc container breakout

#27

Post by geofft »

peterwwillis wrote: post #14
darren0 wrote: post #9

The best fix is to upgrade to 18.09.2. For those that can't do that immediately, backported versions of runc for Docker releases going back to 1.12.6 are available from Rancher at https://github.com/rancher/runc-cve . But please only do that as a temporary workaround until you can properly upgrade to 18.09.2. Please patch if you don't 100% trust all users on your host.

For systems where you already enforce security policies, updating policy is faster than upgrading software, due to fewer build processes, quality control issues, and potential side-effects. If you are using SELinux, verify your containers are running as container_t . If not, verify you are using user namespaces that don't map host root into the container user's namespace. These should mitigate the issue. (as far as t…

I believe that if you're in an environment where users don't have (and can't gain) root inside the container, you're also fine, and if that's your theoretical policy, getting to the point where you 100% enforce that might also be easier than patching.

Re: CVE-2019-5736: runc container breakout

#28

Post by NathanKP »

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/AWS-2019-...

Re: CVE-2019-5736: runc container breakout

#29

Post by [deleted] »

justanother- wrote: post #17
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.

Alternative idea: throw away docker and katacontainers and move to freebsd, where jails were introduced on 14 Mar 2000 (no, seriously, superior technology exists for 19 years - stable, time proven, working). Some more info: https://www.freebsd.org/doc/handbook/jails.html And for quick start: https://github.com/iocage/iocage

[deleted]

Re: CVE-2019-5736: runc container breakout

#30

Post by justanother- »

ajross wrote: post #23
justanother- wrote: post #17

Earlier quoted context omitted.

Alternative idea: throw away docker and katacontainers and move to freebsd, where jails were introduced on 14 Mar 2000 (no, seriously, superior technology exists for 19 years - stable, time proven, working). Some more info: https://www.freebsd.org/doc/handbook/jails.html And for quick start: https://github.com/iocage/iocage

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…

Sure, but there were 19 years of time proofing them. Each product has vulnerabilities which get weeded out when time passes. And for kata and docker, in context of what they are used for, they are bleeding edge.

(from a technical perspective, you would be running jails for years too - so much about platform loyality)

Post reply on HN