3 ms·

Short of CVEs, which are fixed after identification, can you point out other ways to "cause problems" with a tiny webserver serving static content in a containe

Short of CVEs, which are fixed after identification, can you point out other ways to "cause problems" with a tiny webserver serving static content in a container?

jedberg 6y ago
Well, there have been many container breakout CVEs, and I'm sure there will be more: https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=container https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=container But let me ask the question another way. What security do you gain by being in a container instead of on a server without a container?
- cytzol 6y ago
  > What security do you gain by being in a container instead of on a server without a container? I'm not a container guru, but... this is obvious, right? You have to break out the container, which is an extra layer. In order to get root on the server, you need: • Without container: application vulnerability (to gain access to the OS) + kernel vulnerability (to gain access to root) • With container: application vulnerability (to gain access to the container) + container breakout vulnerability (to gain access to the OS) + kernel vulnerability (to gain access to root) You make it sound like I'm missing something — what am I missing here? Edit: are you talking about CVEs like this one (https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-3215 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-3215)? I guess I'm assuming that a container vulnerability will give an attacker less to play with than a kernel vulnerability.
  - xorcist 6y ago
    Are you talking about VMs or containers? If you have an application RCE and a kernel vulnerability, what difference would a running container daemon make?
  - inopinatus 6y ago
    Containers share a platform. They increase attack surface by supplying a vector to any neighbour, by being something that can be attacked at all, and by requiring another control plane that requires credentials, making it a social engineering opportunity as well as being another component that itself can be vulnerable. They are not an additional shell of defence, they do not reduce your blast radius.
    - cytzol 6y ago
      > They increase attack surface by supplying a vector to any neighbour Could you explain what you mean by this? I'm still not getting it. Here's the example I have in mind: I have one application listening on a TCP port, and another one listening on a different port. I don't want the first application to talk to the second application. If they're just two processes on the same machine, they can both see each other, and an attacker who manages to exploit an RCE vulnerability gets access to the port "for free"; if they're both in containers, then they can only see the ports I specify, and it's really easy for me to specify them. This literally does seem like an additional shell of defence to me! What sort of attack would it make worse?
      - inopinatus 6y ago
        Trusting the isolation like this is absolutely misguided, to the extent that it’s in conflict with understanding how computers work. Those who do not remember rowhammer or spectre and their kin are doomed to repeat them. As for your example, there’s no difference between that and OS mediated mandatory access controls, separation of uids, chroot etc. Those capabilities are present irregardless of whether you’re using containers. Anyone selling you on containers as a security measure is pitching snake oil. They are a resource allocation & workload scheduling tool. They may help applications avoid inadvertently treading on one another’s toes e.g. avoiding library conflicts or easing the deployment of, say, QA and showcase environments on the same metal, but it’s intrinsically a shoji wall. There’s even a cultural downside, since developers may make exactly these flawed assumptions about runtime safety, or hard-code paths for config files rather than making them relative to deployment location, make assumptions (implicit or otherwise) about uids and so on, i.e. containers can breed sloppy dev practices.
  - jedberg 6y ago
    Why do you need to access the OS? If you break out of the web server, you have control of the container. You can then launch any sort of internal attack at the access level of the container. You could also launch a DDOS from the container. Most of the bad stuff you can do when you take over a web server doesn't require root access, just user level access, and you get that whether or not it's in a container.

Short of CVEs, which are fixed after identification, can you point out other ways to "cause problems" with a tiny webserver serving static content in a container?

jedberg 6y ago

Well, there have been many container breakout CVEs, and I'm sure there will be more: https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=container https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=container But let me ask the question another way. What security do you gain by being in a container instead of on a server without a container?

cytzol 6y ago
> What security do you gain by being in a container instead of on a server without a container? I'm not a container guru, but... this is obvious, right? You have to break out the container, which is an extra layer. In order to get root on the server, you need: • Without container: application vulnerability (to gain access to the OS) + kernel vulnerability (to gain access to root) • With container: application vulnerability (to gain access to the container) + container breakout vulnerability (to gain access to the OS) + kernel vulnerability (to gain access to root) You make it sound like I'm missing something — what am I missing here? Edit: are you talking about CVEs like this one (https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-3215 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-3215)? I guess I'm assuming that a container vulnerability will give an attacker less to play with than a kernel vulnerability.
- xorcist 6y ago
  Are you talking about VMs or containers? If you have an application RCE and a kernel vulnerability, what difference would a running container daemon make?
- inopinatus 6y ago
  Containers share a platform. They increase attack surface by supplying a vector to any neighbour, by being something that can be attacked at all, and by requiring another control plane that requires credentials, making it a social engineering opportunity as well as being another component that itself can be vulnerable. They are not an additional shell of defence, they do not reduce your blast radius.
  - cytzol 6y ago
    > They increase attack surface by supplying a vector to any neighbour Could you explain what you mean by this? I'm still not getting it. Here's the example I have in mind: I have one application listening on a TCP port, and another one listening on a different port. I don't want the first application to talk to the second application. If they're just two processes on the same machine, they can both see each other, and an attacker who manages to exploit an RCE vulnerability gets access to the port "for free"; if they're both in containers, then they can only see the ports I specify, and it's really easy for me to specify them. This literally does seem like an additional shell of defence to me! What sort of attack would it make worse?
    - inopinatus 6y ago
      Trusting the isolation like this is absolutely misguided, to the extent that it’s in conflict with understanding how computers work. Those who do not remember rowhammer or spectre and their kin are doomed to repeat them. As for your example, there’s no difference between that and OS mediated mandatory access controls, separation of uids, chroot etc. Those capabilities are present irregardless of whether you’re using containers. Anyone selling you on containers as a security measure is pitching snake oil. They are a resource allocation & workload scheduling tool. They may help applications avoid inadvertently treading on one another’s toes e.g. avoiding library conflicts or easing the deployment of, say, QA and showcase environments on the same metal, but it’s intrinsically a shoji wall. There’s even a cultural downside, since developers may make exactly these flawed assumptions about runtime safety, or hard-code paths for config files rather than making them relative to deployment location, make assumptions (implicit or otherwise) about uids and so on, i.e. containers can breed sloppy dev practices.
- jedberg 6y ago
  Why do you need to access the OS? If you break out of the web server, you have control of the container. You can then launch any sort of internal attack at the access level of the container. You could also launch a DDOS from the container. Most of the bad stuff you can do when you take over a web server doesn't require root access, just user level access, and you get that whether or not it's in a container.