4 ms·

> Hacker news, you can shove your comments right up your ...

by JepZ 9y ago

Yetanfou 9y ago
...container?
sbierwagen 9y ago
Yes, very odd. Don't think I'll be upvoting this submission. >Imagine if an entire OS had all the languages packaged this way so that everything could be “dot slashed” and executed but without actually installing the language to your host operating system. This has been technically possible for decades, but the disadvantages (startup time, memory use, disk use) outweigh the advantages. (better security, assuming no VM escape bugs, which is an assumption you absolutely can't make, considering the long list of Xen CVEs) Breezily asserting the superiority of this solution without acknowledging any possible downsides is also strange... more press release than blog post.
- Godel_unicode 9y ago
  Containers aren’t VMs. There’s no VM to escape, and Xen has nothing whatsoever to do with containers. Ironically, there’s a really good explanation of this topic which was given by the author at a conference. Also, this is a write-up about something cool that author discovered. It’s about the fact that dot slash isn’t magic, but rather a feature which can be (ab)used to do something out of the ordinary. Sounds like a blog post to me.
  - sbierwagen 9y ago
    An excellent and helpful correction. But security-wise chroot/runc is even worse than Xen, since the attack surface is so much bigger! https://nvd.nist.gov/vuln/search/results?adv_search=false&form_type=basic&results_type=overview&search_type=all&query=docker https://nvd.nist.gov/vuln/search/results?adv_search=false&fo... https://nvd.nist.gov/vuln/search/results?adv_search=false&form_type=basic&results_type=overview&search_type=all&query=chroot https://nvd.nist.gov/vuln/search/results?adv_search=false&fo...
    - msost 9y ago
      "An excellent and helpful correction, but here is why I am still right."
    - jessfraz 9y ago
      This doesn't use docker or a chroot, it's a pivot root.
    - jessfraz 9y ago
      See first comment about how it's a pivot root and if you are going to claim containers are insecure please first capture the flag on https://contained.af https://contained.af or gfy
      - marcosnils 9y ago
        Thanks jessie and cyphar for making HAN great again!
    - cyphar 9y ago
      tl;dr Docker != runc. runc has only had one known partial container breakout that required host coordination, and all of the runc CVEs are useless in rootless containers (which is what jessfraz is using). Of the vulnerabilities you've listed (while searching "docker") only four were actually runc vulnerabilities, and most required you to be running root inside the container (or required you to have some form of privileged access on the host). Also, runc doesn't use chroot -- we use pivot_root. You've also just done a full-text search for "docker" and several of the CVEs just have the word and are not actually vulnerabilities in "docker" nor runc. I don't understand what this is meant to show. In particular, these are the only vulnerabilities in that list that are arguably related to your point. * CVE-2017-16539 -- a default configuration error allowing a DoS if you're root in a non-user-namespaced container. The PoC in TFA uses user namespaces and thus this attack is pointless. Not to mention you shouldn't run as root anyway, please stop doing that. * CVE-2016-9962 -- a partial container escape if you have another process joining the container, there were also several kernel bugs found as well as a result. Also requires root, and user namespaces had a fix for this in the next kernel version. Again, stop running stuff as root. * CVE-2015-3627 -- an information disclosure that requires a malicious rootfs (so you have to have host-side coordination to set up the rootfs before the container starts), and was never present in "runc" just the library that predated it. * CVE-2015-3629 -- a partial container escape that required significant host-side coordination (you have to change the configuration of the container to be malicious). Also wasn't present in "runc" just the library that predated it. So, there has only ever been one plausible container breakout in runc to-date and it was CVE-2016-9962 (and it still required using bad practices). You could argue that CVE-2016-3697 was also a runc bug, but that code was only used by Docker at the time (more of a library bug than a container breakout bug). CVE-2015-3629 requires you to effectively create the container that you're going to break out of, so not viable from a "bad code in a container" perspective. I'm not excusing these bugs, but they should be put in context. CVEs have CVSS scores for a reason -- they are not all created equal and you need to look at each one individually before coming to conclusions. I do respect the folks who work on Xen, don't get me wrong, but I don't understand this argument for the security of Xen. If I only consider the 11-year-old floppy privilege escalation[1], then runc is already on better footing in terms of "which project had a worse example of a vulnerability resulting in containment escape". Whether this is due to the young age of containers on Linux, or because containers levarage many different security features, I'm not sure. Source: I'm a maintainer of runc, and I found CVE-2016-9962. [1]: https://xenbits.xen.org/xsa/advisory-133.html https://xenbits.xen.org/xsa/advisory-133.html
- natbobc 9y ago
  I think you could've just as easily stated. "Huh interesting what are the downsides?" Suppose that would admit not knowing something... certainly not something we should be encouraging!
na85 9y ago
Maybe it's because this place tends to be quite negative if you don't confirm to a very specific set of norms.
- dang 9y ago
  In my observation those "norms" are always in the eye of the beholder, and people have very contradictory notions of what they supposedly are.

> Hacker news, you can shove your comments right up your ...

by JepZ 9y ago

> Hacker news, you can shove your comments right up your ...

Yetanfou 9y ago

...container?

sbierwagen 9y ago

Yes, very odd. Don't think I'll be upvoting this submission. >Imagine if an entire OS had all the languages packaged this way so that everything could be “dot slashed” and executed but without actually installing the language to your host operating system. This has been technically possible for decades, but the disadvantages (startup time, memory use, disk use) outweigh the advantages. (better security, assuming no VM escape bugs, which is an assumption you absolutely can't make, considering the long list of Xen CVEs) Breezily asserting the superiority of this solution without acknowledging any possible downsides is also strange... more press release than blog post.

Godel_unicode 9y ago
Containers aren’t VMs. There’s no VM to escape, and Xen has nothing whatsoever to do with containers. Ironically, there’s a really good explanation of this topic which was given by the author at a conference. Also, this is a write-up about something cool that author discovered. It’s about the fact that dot slash isn’t magic, but rather a feature which can be (ab)used to do something out of the ordinary. Sounds like a blog post to me.
- sbierwagen 9y ago
  An excellent and helpful correction. But security-wise chroot/runc is even worse than Xen, since the attack surface is so much bigger! https://nvd.nist.gov/vuln/search/results?adv_search=false&form_type=basic&results_type=overview&search_type=all&query=docker https://nvd.nist.gov/vuln/search/results?adv_search=false&fo... https://nvd.nist.gov/vuln/search/results?adv_search=false&form_type=basic&results_type=overview&search_type=all&query=chroot https://nvd.nist.gov/vuln/search/results?adv_search=false&fo...
  - msost 9y ago
    "An excellent and helpful correction, but here is why I am still right."
  - jessfraz 9y ago
    This doesn't use docker or a chroot, it's a pivot root.
  - jessfraz 9y ago
    See first comment about how it's a pivot root and if you are going to claim containers are insecure please first capture the flag on https://contained.af https://contained.af or gfy
    - marcosnils 9y ago
      Thanks jessie and cyphar for making HAN great again!
  - cyphar 9y ago
    tl;dr Docker != runc. runc has only had one known partial container breakout that required host coordination, and all of the runc CVEs are useless in rootless containers (which is what jessfraz is using). Of the vulnerabilities you've listed (while searching "docker") only four were actually runc vulnerabilities, and most required you to be running root inside the container (or required you to have some form of privileged access on the host). Also, runc doesn't use chroot -- we use pivot_root. You've also just done a full-text search for "docker" and several of the CVEs just have the word and are not actually vulnerabilities in "docker" nor runc. I don't understand what this is meant to show. In particular, these are the only vulnerabilities in that list that are arguably related to your point. * CVE-2017-16539 -- a default configuration error allowing a DoS if you're root in a non-user-namespaced container. The PoC in TFA uses user namespaces and thus this attack is pointless. Not to mention you shouldn't run as root anyway, please stop doing that. * CVE-2016-9962 -- a partial container escape if you have another process joining the container, there were also several kernel bugs found as well as a result. Also requires root, and user namespaces had a fix for this in the next kernel version. Again, stop running stuff as root. * CVE-2015-3627 -- an information disclosure that requires a malicious rootfs (so you have to have host-side coordination to set up the rootfs before the container starts), and was never present in "runc" just the library that predated it. * CVE-2015-3629 -- a partial container escape that required significant host-side coordination (you have to change the configuration of the container to be malicious). Also wasn't present in "runc" just the library that predated it. So, there has only ever been one plausible container breakout in runc to-date and it was CVE-2016-9962 (and it still required using bad practices). You could argue that CVE-2016-3697 was also a runc bug, but that code was only used by Docker at the time (more of a library bug than a container breakout bug). CVE-2015-3629 requires you to effectively create the container that you're going to break out of, so not viable from a "bad code in a container" perspective. I'm not excusing these bugs, but they should be put in context. CVEs have CVSS scores for a reason -- they are not all created equal and you need to look at each one individually before coming to conclusions. I do respect the folks who work on Xen, don't get me wrong, but I don't understand this argument for the security of Xen. If I only consider the 11-year-old floppy privilege escalation[1], then runc is already on better footing in terms of "which project had a worse example of a vulnerability resulting in containment escape". Whether this is due to the young age of containers on Linux, or because containers levarage many different security features, I'm not sure. Source: I'm a maintainer of runc, and I found CVE-2016-9962. [1]: https://xenbits.xen.org/xsa/advisory-133.html https://xenbits.xen.org/xsa/advisory-133.html
natbobc 9y ago
I think you could've just as easily stated. "Huh interesting what are the downsides?" Suppose that would admit not knowing something... certainly not something we should be encouraging!

na85 9y ago

Maybe it's because this place tends to be quite negative if you don't confirm to a very specific set of norms.

dang 9y ago
In my observation those "norms" are always in the eye of the beholder, and people have very contradictory notions of what they supposedly are.