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

41–50 of 102 posts

Re: CVE-2019-5736: runc container breakout

#41

Post by geofft »

pjmlp wrote: post #33
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.

In 2018, 68% of Linux CVEs were caused by C's memory corruption features. Source, Google talk at Linux Kernel Summit 2018.

See also Fish in a Barrel's Twitter account: https://twitter.com/LazyFishBarrel The vast majority of security updates these days are memory unsafety.

(Fish in a Barrel, LLC is a nonexistent security research "company" consisting of people setting up fuzzers on the weekend and then proceeding to shoot fish in a barrel.)

Re: CVE-2019-5736: runc container breakout

#42

Post by [deleted] »

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.

[deleted]

Re: CVE-2019-5736: runc container breakout

#43

Post by pizlonator »

ebeip90 wrote: post #20
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.

Probably only off by an order of magnitude. Check out Dmitry’s szykaller slides. https://events.linuxfoundation.org/wp-content/uploads/2017/1... Edit: I missed the “RCE” context. Most of these are just privescs or memory disclosures.

Wasn’t even serious about this, but now that y’all are playing along, I’ll just dig in for fun.

It’s interesting that Linux kernel bug stats contradict my bold bet. But I’m imagining rando C code here, not necessarily open source, not necessarily in the kernel, not necessarily tested and reviewed the same way. This code is at least open source but I dunno to what extent this newly added code path in runc gets the kind of shaking out that makes kernel code solid.

Runc aside, I expect most C code to have a higher rate of every kind of bug than the kernel.

Re: CVE-2019-5736: runc container breakout

#44

Post by barbecue_sauce »

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

Is there a centralized jail image repository with images of jails running popular open source software applications that I can search from the command line and spin up locally or in a cluster with a few commands? Can I easily replicate and distribute an image of a jail? Because that is what Docker offers.

Re: CVE-2019-5736: runc container breakout

#45

Post by wahern »

pjmlp wrote: post #33
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.

In 2018, 68% of Linux CVEs were caused by C's memory corruption features. Source, Google talk at Linux Kernel Summit 2018.

And how many of those were related to the difficulty of managing IPC across user/kernel boundaries, DMA, mbuf-based networking code, eBPF JIT'ing, etc? So-called memory safe languages don't help with any of that.

I'll take your memory safe languages and up the ante with microkernels, which actually help immensely in all those cases. But Linux isn't going to go that route, either.

Re: CVE-2019-5736: runc container breakout

#46

Post by nisa »

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

...or Solaris Zones / illumos Zones (2005) - you can even run Docker on them.

Re: CVE-2019-5736: runc container breakout

#47

Post by howiroll »

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

19 years without vulnerability because no one uses it seriously. Seriously. Deal with it.

Re: CVE-2019-5736: runc container breakout

#49

Post by brauner »

iwalton3 wrote: post #15
tyingq wrote: post #12

Is this something that non-privileged containers mitigates? Curious what the big barriers are to this. I know they exist, but aren't used widely...I assume because some functionality doesn't work.

Yes. The lxc commit[1] states that this issue only affects privileged containers. No CVE has been issued for lxc because they consider privileged containers to be insecure. In my experience unprivileged containers work for most tasks, but there is breakage in some areas. Usually the issues are simple to resolve, like disabling OOM adjustments in systemd or changing the idmap range in winbind to be within the namespac…

I've also written a smallish blogpost about this CVE. I'm a LX{C,D} maintainer and I've worked with Aleksa the runC maintainer together on a fix for this CVE: https://brauner.github.io/2019/02/12/privileged-containers.h...

Re: CVE-2019-5736: runc container breakout

#50

Post by TheDong »

pizlonator wrote: post #43
ebeip90 wrote: post #20

Earlier quoted context omitted.

Probably only off by an order of magnitude. Check out Dmitry’s szykaller slides. https://events.linuxfoundation.org/wp-content/uploads/2017/1... Edit: I missed the “RCE” context. Most of these are just privescs or memory disclosures.

Wasn’t even serious about this, but now that y’all are playing along, I’ll just dig in for fun. It’s interesting that Linux kernel bug stats contradict my bold bet. But I’m imagining rando C code here, not necessarily open source, not necessarily in the kernel, not necessarily tested and reviewed the same way. This code is at least open source but I dunno to what extent this newly added code path in runc gets the kin…

Large swathes of C code can't have an RCE by definition.

Any C code which is not available on the network (e.g. C code running on your refrigerator) by definition cannot have a remote code execution vulnerability.

Lots of software, such as the 'top' utility, makes no networking related calls in the codebase, so any instances of bugs would be buffer overflows or crashes, but not remotely exploitable by the usual meaning.

I think that you vastly under-estimate how difficult it is to accidentally write a remotely exploitable bug.

Sure, buffer overflows and undefined behavior happen all the time in C code. Those bugs might be 1 per 100 lines even in the average C code.

of those, hardly any will be network exploitable. Relatively little code will be handling data sourced from the network.

Post reply on HN