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

51–60 of 102 posts

Re: CVE-2019-5736: runc container breakout

#51

Post by pizlonator »

TheDong wrote: post #50
pizlonator wrote: post #43

Earlier quoted context omitted.

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 meani…

That's sort of literally true except that it's hard to predict how code will be used in the future.

For example, I bet that some dude writing an image decoder in the 90's was thinking "it's cool, I don't have to worry about security" because he just knew that his code wasn't going to be remotely exploitable.

Anyway, my original comment was supposed to be as funny as your handle. I guess the humor ended up being just in how seriously folks took it.

The part I'm not joking about is that folks always underestimate the amount of security bugs that will be found in a piece of code in the future, either because the code ends up used in a way that wasn't predicted, or because some really great bug was just waiting for the right kind of genius to uncover it.

Re: CVE-2019-5736: runc container breakout

#52

Post by pjmlp »

wahern wrote: post #45
pjmlp wrote: post #33

Earlier quoted context omitted.

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.

Plenty of them related to lack of bounds checking handling strings and arrays.

Google has been pushing for the Kernel Self Preservation project for quite a while now, which Android and ChromeOS make best use of, also a reason why the NDK is so constrained on Android.

Security in the kernel also had quite a few talks at Linux Conf 2019, just recently in New Zealand.

Re: CVE-2019-5736: runc container breakout

#53

Post by justanother- »

howiroll wrote: post #47
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

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

Taken from some other thread: "Most "unix" admins only know linux and will advocate for it vigorously because it is so much better than.. "what do you use again? Fedora? Ah, FreeBSD, something with F, I knew it!""

Re: CVE-2019-5736: runc container breakout

#54

Post by SteveNuts »

geofft wrote: post #38
justanother- wrote: post #30

Earlier quoted context omitted.

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)

Vulnerabilities don't get weeded out by time like radioisotopes decaying. Vulnerabilities get weeded out by attention, and attention happens when people use a system in production to protect a high-value target. Jails haven't been used to protect as many high-value targets as Linux containers have. This is not a comment on the technical quality of jails. It may well be a comment on the world's anti-FreeBSD prejudice.…

> Jails haven't been used to protect as many high-value targets as Linux containers have

This is not true in my experience at all. It may be true that it hasn't been in use at startups until Docker came out, but a few large, established companies I've worked at absolutely used Jails or Zones to protect their most valuable IP. And have been for a long time.

Re: CVE-2019-5736: runc container breakout

#55

Post by duncaen »

justanother- wrote: post #53
howiroll wrote: post #47

Earlier quoted context omitted.

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

Taken from some other thread: "Most "unix" admins only know linux and will advocate for it vigorously because it is so much better than.. "what do you use again? Fedora? Ah, FreeBSD, something with F, I knew it!""

Maybe they just want exploit mitigation techniques like ASLR.

Re: CVE-2019-5736: runc container breakout

#56

Post by jhealy »

sethvargo wrote: post #35

Hey all - Seth from Google here. Please let us know if you have any questions regarding GKE or questions about the upgrade process. I'm also happy to escalate any feedback to our internal product and engineering teams. Here's link to our security posting with more information and upgrade procedures: https://cloud.google.com/kubernetes-engine/docs/security-bul...

I'm interested in why COS is unaffected - is it due to the read-only root filesystem?

Re: CVE-2019-5736: runc container breakout

#57

Post by achillean »

nineteen999 wrote: post #31
achillean wrote: post #18

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

So inexperienced developers are just as likely to reach for Docker as experienced ones? I wonder how many of those 4,000 docker daemons are running/managing containers of dubious origin.

Around 10% of them are running cryptominers so it looks like there are already people out there compromising these public Docker instances.

Re: CVE-2019-5736: runc container breakout

#58

Post by wicket »

> 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 work, let alone the implications of root access. I've interviewed candidates who claim to know Docker but can't even tell me how Docker differs from traditional virtualisation or how it achieves its isolation. The best explanation that most of them come up with is, "Docker containers are more lightweight".

This sort of vulnerability should have been a non-issue but it has gained attention due to the sheer amount of incorrectly configured containers in the wild. This was an accident waiting to happen, and I doubt we've heard the last of this sort of thing.

Re: CVE-2019-5736: runc container breakout

#59

Post by tyingq »

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…

Docker runs privileged by default, doesn't it? Seems unfair to put all the blame on the end users of it.

Re: CVE-2019-5736: runc container breakout

#60

Post by cpuguy83 »

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…

The thing is, you would have to disallow running as root in the system itself, including suid binaries and other things (e.g. docker exec -u root).

User namespaces forces this. It's not just about not running as root, it's making sure the container cannot map to the real UID 0.

Post reply on HN