5 ms·

In context, https://github.com/moby/moby/issues/22054#issuecomment-962202433 https://github.com/moby/moby/issues/22054#issuecomment-96220... and following: > D

In context, https://github.com/moby/moby/issues/22054#issuecomment-962202433 https://github.com/moby/moby/issues/22054#issuecomment-96220... and following: > Docker containers in the 172.16.0.0/12 ip range are definitely reachable from external hosts. All it requires is a custom route on the attacker's machine that directs traffic bound for 172.16.0.0/12 through the victim's machine. > Notice that the common advice of binding the published port to 127.0.0.1 does not protect the container from external access. ... > You don't even have to --publish.

koolba 4y ago
Would this attack require having control of a machine on the same local network? Otherwise how would you route that packet to the target machine?
- infotogivenm 4y ago
  Yes, I believe so, although you need “privileged network access” on the box - meaning you can craft random IP packets, not just “control” of the box. So on the LAN or otherwise in-path for the route for that subnet’s responses.
  - jandrese 4y ago
    Aren't you just crafting a packet to a 172.17.0.0/16 address on port 80? That requires no special permission whatsoever.
    - infotogivenm 4y ago
      If your compromised box has a route already for that subnet and machine yes. That would be odd though I think.
- jandrese 4y ago
  Right, you aren't going to send that packet over the Internet, and you'll only getting it through local routers that have the routes you need, which should not be common.
  - sigg3 4y ago
    Might be common with IoT devices, cloud network equipment etc. :|
- ranger_danger 4y ago
  yes
infotogivenm 4y ago
I believe this is only true when ipv4 forwarding kernel tunable is enabled, but am not sure. Does anyone know?
- ranger_danger 4y ago
  If you disable it at least, your containers will no longer have internet access.
  - infotogivenm 4y ago
    Had to look it up, you’re right: https://github.com/moby/moby/issues/490 https://github.com/moby/moby/issues/490 It’s required by docker, ugh.
    - metadat 4y ago
      See sibling comment: https://news.ycombinator.com/item?id=31841487 https://news.ycombinator.com/item?id=31841487
cxcorp 4y ago
This is even worse than falsely binding to 127.0.0.1. If I don't publish a port in a container, I expect to *not publish any ports*.
tinco 4y ago
Eh, isn't the real story then that Linux will route random incoming traffic on any interface? Even if you haven't configured it as a router? I know whoever was in charge of configuring Dockers iptables routes should have known this and messed up, but that is fucked up.
- jeroenhd 4y ago
  I'm a bit confused; as far as I know Linux only forwards packets on interfaces where you've enabled routing, doesn't it? If you set up: net.ipv4.ip_forward=0 net.ipv4.conf.eth0.forwarding=0 net.ipv4.conf.docker.forwarding=1 I'm pretty sure this isn't an issue, right? My guess is that the real real story is probably that every guide on the internet says to just set net.ipv4.ip_forward=1 and that nobody bothers to stop and read up on the sysctl parameters they're copy/pasting from the internet. For this attack to succeed, the attacker also needs to be on the same network or have their upstream ISPs accept plain external traffic towards internal networks. Executing the PoC on Linux without being in the same subnet won't even be accepted (though raw sockets may still send out traffic towards the host that will probably get filtered somewhere along the way).
  - forbiddenlake 4y ago
    This doesn't work. Breaks traffic out (below) and in. # sysctl net.ipv4.ip_forward net.ipv4.conf.enp8s0.forwarding net.ipv4.conf.docker0.forwarding net.ipv4.ip_forward = 1 net.ipv4.conf.enp8s0.forwarding = 1 net.ipv4.conf.docker0.forwarding = 1 # docker run --rm alpine/curl -sI --max-time 5 http://1.1.1.1 | head -n2 HTTP/1.1 301 Moved Permanently Server: cloudflare # sysctl net.ipv4.conf.enp8s0.forwarding=0 net.ipv4.conf.enp8s0.forwarding = 0 # docker run --rm alpine/curl -I --max-time 5 http://1.1.1.1 | head -n2 % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 0 0 0 0 0 0 0 0 --:--:-- 0:00:05 --:--:-- 0 curl: (28) Connection timed out after 5000 milliseconds
- lmm 4y ago
  > Linux will route random incoming traffic on any interface? Even if you haven't configured it as a router? "configuring Linux as a router" is exactly what "adding an iptables rule that routes" is. That's what it's for, that's how you do it.
Spivak 4y ago
Well yeah, you turned on ip forwarding and created a network on your host that can be reached. Imagine this was a VM host and those networks were meant to be routable, how else could it work? Are people just now discovering the FORWARD chain?
- theptip 4y ago
  Like the OP said, > most Linux users do not know how to configure their firewalls and have not added any rules to DOCKER-USER. The few users that do know how to configure their firewalls are likely to be unpleasantly surprised that their existing FORWARD rules have been preceded by Docker's own forwarding setup
mark-wagner 4y ago
I'm confused. Does docker change the routing table? Otherwise there will be no route back to the attacker's machine. Also, if 172.16.0.0/12 is bound to the docker0 interface then the kernel will see packets from IPs in that range that come in on other interfaces as martians and drop them.

koolba 4y ago

Would this attack require having control of a machine on the same local network? Otherwise how would you route that packet to the target machine?

infotogivenm 4y ago
Yes, I believe so, although you need “privileged network access” on the box - meaning you can craft random IP packets, not just “control” of the box. So on the LAN or otherwise in-path for the route for that subnet’s responses.
- jandrese 4y ago
  Aren't you just crafting a packet to a 172.17.0.0/16 address on port 80? That requires no special permission whatsoever.
  - infotogivenm 4y ago
    If your compromised box has a route already for that subnet and machine yes. That would be odd though I think.
jandrese 4y ago
Right, you aren't going to send that packet over the Internet, and you'll only getting it through local routers that have the routes you need, which should not be common.
- sigg3 4y ago
  Might be common with IoT devices, cloud network equipment etc. :|
ranger_danger 4y ago
yes

infotogivenm 4y ago

I believe this is only true when ipv4 forwarding kernel tunable is enabled, but am not sure. Does anyone know?

ranger_danger 4y ago
If you disable it at least, your containers will no longer have internet access.
- infotogivenm 4y ago
  Had to look it up, you’re right: https://github.com/moby/moby/issues/490 https://github.com/moby/moby/issues/490 It’s required by docker, ugh.
  - metadat 4y ago
    See sibling comment: https://news.ycombinator.com/item?id=31841487 https://news.ycombinator.com/item?id=31841487

cxcorp 4y ago

This is even worse than falsely binding to 127.0.0.1. If I don't publish a port in a container, I expect to *not publish any ports*.

tinco 4y ago

Eh, isn't the real story then that Linux will route random incoming traffic on any interface? Even if you haven't configured it as a router? I know whoever was in charge of configuring Dockers iptables routes should have known this and messed up, but that is fucked up.

jeroenhd 4y ago
I'm a bit confused; as far as I know Linux only forwards packets on interfaces where you've enabled routing, doesn't it? If you set up: net.ipv4.ip_forward=0 net.ipv4.conf.eth0.forwarding=0 net.ipv4.conf.docker.forwarding=1 I'm pretty sure this isn't an issue, right? My guess is that the real real story is probably that every guide on the internet says to just set net.ipv4.ip_forward=1 and that nobody bothers to stop and read up on the sysctl parameters they're copy/pasting from the internet. For this attack to succeed, the attacker also needs to be on the same network or have their upstream ISPs accept plain external traffic towards internal networks. Executing the PoC on Linux without being in the same subnet won't even be accepted (though raw sockets may still send out traffic towards the host that will probably get filtered somewhere along the way).
- forbiddenlake 4y ago
  This doesn't work. Breaks traffic out (below) and in. # sysctl net.ipv4.ip_forward net.ipv4.conf.enp8s0.forwarding net.ipv4.conf.docker0.forwarding net.ipv4.ip_forward = 1 net.ipv4.conf.enp8s0.forwarding = 1 net.ipv4.conf.docker0.forwarding = 1 # docker run --rm alpine/curl -sI --max-time 5 http://1.1.1.1 | head -n2 HTTP/1.1 301 Moved Permanently Server: cloudflare # sysctl net.ipv4.conf.enp8s0.forwarding=0 net.ipv4.conf.enp8s0.forwarding = 0 # docker run --rm alpine/curl -I --max-time 5 http://1.1.1.1 | head -n2 % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 0 0 0 0 0 0 0 0 --:--:-- 0:00:05 --:--:-- 0 curl: (28) Connection timed out after 5000 milliseconds
lmm 4y ago
> Linux will route random incoming traffic on any interface? Even if you haven't configured it as a router? "configuring Linux as a router" is exactly what "adding an iptables rule that routes" is. That's what it's for, that's how you do it.

Spivak 4y ago

Well yeah, you turned on ip forwarding and created a network on your host that can be reached. Imagine this was a VM host and those networks were meant to be routable, how else could it work? Are people just now discovering the FORWARD chain?

theptip 4y ago
Like the OP said, > most Linux users do not know how to configure their firewalls and have not added any rules to DOCKER-USER. The few users that do know how to configure their firewalls are likely to be unpleasantly surprised that their existing FORWARD rules have been preceded by Docker's own forwarding setup

mark-wagner 4y ago

I'm confused. Does docker change the routing table? Otherwise there will be no route back to the attacker's machine. Also, if 172.16.0.0/12 is bound to the docker0 interface then the kernel will see packets from IPs in that range that come in on other interfaces as martians and drop them.