4 ms·

All of these escapes rely on some obvious explicit reduction of the isolation guarantees. If you know how to escape a simple docker container invoked with defau

All of these escapes rely on some obvious explicit reduction of the isolation guarantees. If you know how to escape a simple docker container invoked with default parameters such as `docker run --rm -it ubuntu /bin/bash` I'm sure many people would be interested.

paxys 3y ago
"Escapes" is a vaguely defined term, but considering basic escalation of privilege: - Networking is the obvious one in this scenario. By default (on Docker/LXC/others) all containers are on the same virtual bridge and can communicate with each other. Even with some additional configuration and isolation it is possible to MITM attack other containers on the same host. - It is very easy to DDoS adjacent containers e.g. by spamming signals, forking new processes, creating files. There is again no default safeguard against this.
- charcircuit 3y ago
  If you give a container access to the network, then yes it will have access to the network. That isn't an escape. cgroups can prevent containers from using too much memory or cpu
  - im3w1l 3y ago
    I think we must be careful not to use no-true-scotsman here. Imo, an attack should be considered valid if it works against a typical config - one you would arrive at following a popular tutorial, rather than requiring that it must work against an ideal config.
    - charcircuit 3y ago
      The definition of escaping a container (namespace) is being able to interact with resources not in the namespaces of the process. If a process's network namespace contains a network device then it is not an escape to use it by definition. If the network namespace for a process contains no devices then being able to use a network device would be an escape.
    - lmeyerov 3y ago
      Specifying networks is one of the main docker compose commands and seems pretty normal: services: your_service: image: your_image networks: isolated_network: another_service: image: another_image # This service is on the default network I'd be curious how a vanilla (actual) networking setup is full of holes...
  - ec109685 3y ago
    If one container is OOM’ing incessantly, it can disrupt other containers as the system tries to page out read only pages furiously.
    - deleted 3y ago
      [deleted]
- cangeroo 3y ago
  Can you provide more details on how a container can MITM other containers? Does that also apply to Kubernetes workloads? And does that then require an encrypted service mesh (e.g. Linkerd) or TLS between services?
  - ec109685 3y ago
    You have to give your container NET_RAW capability to allow MITM attacks. Still a good idea to use tls.
tptacek 3y ago
The standard way to escape a simple Docker container with default privileges is to use a kernel LPE vulnerability. Kernel LPEs are common enough that they're found and patched without major news stories written about them.

paxys 3y ago

"Escapes" is a vaguely defined term, but considering basic escalation of privilege: - Networking is the obvious one in this scenario. By default (on Docker/LXC/others) all containers are on the same virtual bridge and can communicate with each other. Even with some additional configuration and isolation it is possible to MITM attack other containers on the same host. - It is very easy to DDoS adjacent containers e.g. by spamming signals, forking new processes, creating files. There is again no default safeguard against this.

charcircuit 3y ago
If you give a container access to the network, then yes it will have access to the network. That isn't an escape. cgroups can prevent containers from using too much memory or cpu
- im3w1l 3y ago
  I think we must be careful not to use no-true-scotsman here. Imo, an attack should be considered valid if it works against a typical config - one you would arrive at following a popular tutorial, rather than requiring that it must work against an ideal config.
  - charcircuit 3y ago
    The definition of escaping a container (namespace) is being able to interact with resources not in the namespaces of the process. If a process's network namespace contains a network device then it is not an escape to use it by definition. If the network namespace for a process contains no devices then being able to use a network device would be an escape.
  - lmeyerov 3y ago
    Specifying networks is one of the main docker compose commands and seems pretty normal: services: your_service: image: your_image networks: isolated_network: another_service: image: another_image # This service is on the default network I'd be curious how a vanilla (actual) networking setup is full of holes...
- ec109685 3y ago
  If one container is OOM’ing incessantly, it can disrupt other containers as the system tries to page out read only pages furiously.
  - deleted 3y ago
    [deleted]
cangeroo 3y ago
Can you provide more details on how a container can MITM other containers? Does that also apply to Kubernetes workloads? And does that then require an encrypted service mesh (e.g. Linkerd) or TLS between services?
- ec109685 3y ago
  You have to give your container NET_RAW capability to allow MITM attacks. Still a good idea to use tls.

tptacek 3y ago

The standard way to escape a simple Docker container with default privileges is to use a kernel LPE vulnerability. Kernel LPEs are common enough that they're found and patched without major news stories written about them.