Hacker News Reader

Comment by harporoeder | Hacker News Reader

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.

View on HN

"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.

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

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.

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.

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...

If one container is OOM’ing incessantly, it can disrupt other containers as the system tries to page out read only pages furiously.

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?

You have to give your container NET_RAW capability to allow MITM attacks.

Still a good idea to use tls.

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.

Reply on news.ycombinator.com