Comment by nickjj | Hacker News Reader

Comment by nickjj | Hacker News Reader

Can someone explain how that proof of concept in the gist applies to a production environment?

For example, let's say I take this exact command from the gist:

    docker run -e POSTGRES_PASSWORD=password -p 127.0.0.1:5432:5432 postgres

And run that on a VPS somewhere out in the world, let's say it's on a public IP address of 106.12.52.111 (I completely made up this IP address btw).

How can you sitting on your dev box on a different network open a psql connection to 106.12.52.111 on port 5432 to the point where you haven't been blocked by iptables?

The part I don't get is the gist mentions:

> An attacker that sends traffic to 172.17.0.2:80 through the docker host will match the rule above and successfully connect to the container, obviating any security benefit of binding the published port on the host to 127.0.0.1. What's worse, users who bind their published ports to 127.0.0.1 operate under a false sense of security and may not bother taking further precautions against unintentional exposure.

In the above example how is someone going to send traffic to 172.17.0.2:80 through the Docker host from a box on a different network than the Docker host?

Also is this still exploitable if you drop everything at the iptables level before you start using Docker?

For example all of my iptables configs start with:

    :INPUT DROP [0:0]
    :FORWARD DROP [0:0]
    :OUTPUT ACCEPT [0:0]

> In the above example how is someone going to send traffic to 172.17.0.2:80 through the Docker host from a box on a different network than the Docker host?

The attacker and host will generally need to be on the same network so that the attacker's packets are not dropped because they are addressed to a non-routable private IP address.

You could access the containers at 106.12.52.111 if you were in the same network (e.g. 106.12.52.0/24) and the packets did not have to traverse a router.

> Also is this still exploitable if you reject everything at the iptables level before you start using Docker?

Yes. Docker appends the FORWARD chain with custom rules that explicitly forward traffic to published ports.

> You could access the containers at 106.12.52.111 if you were in the same network (e.g. 106.12.52.0/24) and the packets did not have to traverse a router.

Ok thanks, that's sort of what I thought (you had to be on the same network) but I wasn't 100% on that because networking has a lot of rabbit holes.

Your gist is very well written and a great find but based on the scope of the vulnerability this wouldn't be classified as a catastrophic event right?

If it's only limited to the attacker and the Docker host being on the same network while packets never go through a router then it's not an issue for the common case of someone hosting their web app or service on a VPS somewhere on the internet and have used 127.0.0.1:XXXX:XXXX to publish a port (perhaps their web app is published to localhost so nginx running directly on the Docker host can reverse proxy it -- this is what I've done for years now).

Reply on news.ycombinator.com