5 ms·

Show me how you will escape a docker sandbox.

by ashishb 9mo ago

staticassertion 9mo ago
Exploit the Linux kernel underneath it (not the only way, just the obvious one). Docker is a security boundary but it is not suitable for "I'm running arbitrary code". That is to say, Docker is typically a security win because you get things like seccomp and user/DAC isolation "for free". That's great. That's a win. Typically exploitation requires a way to get execution in the environment plus a privilege escalation. The combination of those two things may be considered sufficient. It is not sufficient for "I'm explicitly giving an attacker execution rights in this environment" because you remove the cost of "get execution in the environment" and the full burden is on the kernel, which is not very expensive to exploit.
- ashishb 9mo ago
  > Exploit the Linux kernel underneath it (not the only way, just the obvious one). Docker is a security boundary but it is not suitable for "I'm running arbitrary code". Dockler is better for running arbitrary code compared to the direct `npm install <random-package>` that's common these days. I moved to a Dockerized sandbox[1], and I feel much better now against such malicious packages. 1 - https://github.com/ashishb/amazing-sandbox
  - staticassertion 9mo ago
    It's better than nothing, obviously. But I don't consider `npm install <random-package>` to be equivalent to "RCE as a service", although it's somewhat close. I definitely wouldn't recommend `npm install <actually a random package>`, even in Docker. I also implemented `insanitybit/cargo-sandbox` using Docker but that doesn't mean I think `insanitybit/cargo-sandbox` is a sufficient barrier to arbitrary code execution, which is why I also had a hardened `cargo add` that looked for typosquatting of package names, and why I think package manager security in general needs to be improved. You can and should feel better about running commands like that in a container, as I said - seccomp and DAC are security boundaries. I wouldn't say "you should feel good enough to run an open SSH server and publish it for anyone to use".
    - ashishb 9mo ago
      > definitely wouldn't recommend `npm install <actually a random package>`, even in Docker. That's not the main attack vector. The attack vector is some random dependency that is used by a lot of popular packages, which you `npm install` indirectly.
      - staticassertion 9mo ago
        That doesn't change what I said. It definitely doesn't change what I said about docker as a security boundary. Again, it's great to run `npm` in a container. I do that too because it's the lowest effort solution I have available.
    - quotemstr 9mo ago
      > `npm install <random-package>` to be equivalent to "RCE as a service" It is literally that. When you write "npm install foo", npm will proceed to install the package called "foo" and then run its installation scripts. It's as if you'd run curl | bash. That npm install script can do literally anything your shell in your terminal can do. It's not "somewhat close" to RCE. It is literally, exactly, fully, completely RCE delivered as a god damn service to which you connect over the internet.
      - staticassertion 9mo ago
        I'm familiar with how build scripts work. As mentioned, I build insanitybit/cargo-sandbox exactly to deal with malicious build scripts. The reason I consider it different from "I'm opening SSH to the public, anyone can run a shell" is because the attack typically has to either be through a random package, which significantly reduces exposure, or through a compromised package, which requires an additional attack. Basically, somewhere along the way, something else had to go wrong if `npm install <x>` gives an attacker code execution, whereas "I'm giving a shell to the public" involves nothing else going wrong. Running a command yourself that may include code you don't expect is not, to me, the same as arbitrary code execution. It often implies it but I don't consider those to be identical. You can disagree with whether or not this meaningfully changes things (I don't feel strongly about it), but then I'd just point to "I don't think it's a sufficient barrier for either threat model but it's still an improvement". That isn't to downplay the situation at all. Once again, > that doesn't mean I think `insanitybit/cargo-sandbox` is a sufficient barrier to arbitrary code execution, which is why I also had a hardened `cargo add` that looked for typosquatting of package names, and why I think package manager security in general needs to be improved.
neoCrimeLabs 9mo ago
This is a well understood and well documented subject. Do your own research. Start here to help give you ideas for what to research: https://linuxsecurity.com/features/what-is-a-container-escape-vulnerability https://linuxsecurity.com/features/what-is-a-container-escap...
- ashishb 9mo ago
  > This is a well understood and well documented subject. Do your own research. Anything including GNU/Linux kernel can be broken with such security vulnerabilities. This is not a weakness in the design of containers. `npm install`, on the other hand, is broken by design (due to post-install.
  - neoCrimeLabs 9mo ago
    > This is not a weakness in the design of containers. Partially correct. Many container escapes are also because the security of the underlying host, container runtime, or container itself was poorly or inconsistently implemented. This creates gaps that allow escapes from the container. There is a much larger potential for mistakes, creating a much larger attack surface. This is in addition to kernel vulnerabilities. While you can implement effective hardening across all the layers, the potential for misconfiguration is still there, therefore there is still a large attack surface. While a virtual host can be escaped from, the attack surface is much smaller, leaving less room for potential escapes. This is why containers are considered riskier for a sandbox than a virtual host. Which one you use, and why, really should depend on your use case and threat model. Sad to say it, a disappointing amount of people don't put much hardening into their container environments, including production k8s clusters. So it's much easier to say that a virtual host is better for sandboxing than containers, because many people are less likely to get it wrong.
    - ashishb 9mo ago
      > Many container escapes are also because the security of the underlying host, container runtime, or container itself was poorly or inconsistently implemented. Sure, so running `npm install` inside the container is no worse than `npm install` on my machine. And in most cases, it is much better.

Show me how you will escape a docker sandbox.

by ashishb 9mo ago

Show me how you will escape a docker sandbox.

Exploit the Linux kernel underneath it (not the only way, just the obvious one). Docker is a security boundary but it is not suitable for "I'm running arbitrary code". That is to say, Docker is typically a security win because you get things like seccomp and user/DAC isolation "for free". That's great. That's a win. Typically exploitation requires a way to get execution in the environment plus a privilege escalation. The combination of those two things may be considered sufficient. It is not sufficient for "I'm explicitly giving an attacker execution rights in this environment" because you remove the cost of "get execution in the environment" and the full burden is on the kernel, which is not very expensive to exploit.

ashishb 9mo ago
> Exploit the Linux kernel underneath it (not the only way, just the obvious one). Docker is a security boundary but it is not suitable for "I'm running arbitrary code". Dockler is better for running arbitrary code compared to the direct `npm install <random-package>` that's common these days. I moved to a Dockerized sandbox[1], and I feel much better now against such malicious packages. 1 - https://github.com/ashishb/amazing-sandbox
- staticassertion 9mo ago
  It's better than nothing, obviously. But I don't consider `npm install <random-package>` to be equivalent to "RCE as a service", although it's somewhat close. I definitely wouldn't recommend `npm install <actually a random package>`, even in Docker. I also implemented `insanitybit/cargo-sandbox` using Docker but that doesn't mean I think `insanitybit/cargo-sandbox` is a sufficient barrier to arbitrary code execution, which is why I also had a hardened `cargo add` that looked for typosquatting of package names, and why I think package manager security in general needs to be improved. You can and should feel better about running commands like that in a container, as I said - seccomp and DAC are security boundaries. I wouldn't say "you should feel good enough to run an open SSH server and publish it for anyone to use".
  - ashishb 9mo ago
    > definitely wouldn't recommend `npm install <actually a random package>`, even in Docker. That's not the main attack vector. The attack vector is some random dependency that is used by a lot of popular packages, which you `npm install` indirectly.
    - staticassertion 9mo ago
      That doesn't change what I said. It definitely doesn't change what I said about docker as a security boundary. Again, it's great to run `npm` in a container. I do that too because it's the lowest effort solution I have available.
  - quotemstr 9mo ago
    > `npm install <random-package>` to be equivalent to "RCE as a service" It is literally that. When you write "npm install foo", npm will proceed to install the package called "foo" and then run its installation scripts. It's as if you'd run curl | bash. That npm install script can do literally anything your shell in your terminal can do. It's not "somewhat close" to RCE. It is literally, exactly, fully, completely RCE delivered as a god damn service to which you connect over the internet.
    - staticassertion 9mo ago
      I'm familiar with how build scripts work. As mentioned, I build insanitybit/cargo-sandbox exactly to deal with malicious build scripts. The reason I consider it different from "I'm opening SSH to the public, anyone can run a shell" is because the attack typically has to either be through a random package, which significantly reduces exposure, or through a compromised package, which requires an additional attack. Basically, somewhere along the way, something else had to go wrong if `npm install <x>` gives an attacker code execution, whereas "I'm giving a shell to the public" involves nothing else going wrong. Running a command yourself that may include code you don't expect is not, to me, the same as arbitrary code execution. It often implies it but I don't consider those to be identical. You can disagree with whether or not this meaningfully changes things (I don't feel strongly about it), but then I'd just point to "I don't think it's a sufficient barrier for either threat model but it's still an improvement". That isn't to downplay the situation at all. Once again, > that doesn't mean I think `insanitybit/cargo-sandbox` is a sufficient barrier to arbitrary code execution, which is why I also had a hardened `cargo add` that looked for typosquatting of package names, and why I think package manager security in general needs to be improved.

neoCrimeLabs 9mo ago

This is a well understood and well documented subject. Do your own research. Start here to help give you ideas for what to research: https://linuxsecurity.com/features/what-is-a-container-escape-vulnerability https://linuxsecurity.com/features/what-is-a-container-escap...

ashishb 9mo ago
> This is a well understood and well documented subject. Do your own research. Anything including GNU/Linux kernel can be broken with such security vulnerabilities. This is not a weakness in the design of containers. `npm install`, on the other hand, is broken by design (due to post-install.
- neoCrimeLabs 9mo ago
  > This is not a weakness in the design of containers. Partially correct. Many container escapes are also because the security of the underlying host, container runtime, or container itself was poorly or inconsistently implemented. This creates gaps that allow escapes from the container. There is a much larger potential for mistakes, creating a much larger attack surface. This is in addition to kernel vulnerabilities. While you can implement effective hardening across all the layers, the potential for misconfiguration is still there, therefore there is still a large attack surface. While a virtual host can be escaped from, the attack surface is much smaller, leaving less room for potential escapes. This is why containers are considered riskier for a sandbox than a virtual host. Which one you use, and why, really should depend on your use case and threat model. Sad to say it, a disappointing amount of people don't put much hardening into their container environments, including production k8s clusters. So it's much easier to say that a virtual host is better for sandboxing than containers, because many people are less likely to get it wrong.
  - ashishb 9mo ago
    > Many container escapes are also because the security of the underlying host, container runtime, or container itself was poorly or inconsistently implemented. Sure, so running `npm install` inside the container is no worse than `npm install` on my machine. And in most cases, it is much better.