port 900 is exposed to the world in fpm example docker-compose. may provide malware access to container.

[uriba107]

--- Update --- Upon further investigation Issue seems to be related to exposed php-fpm port. I'm verifying it's the root cause.

--- Original report --- latest-fpm-alpine (2021/4/1) https://hub.docker.com/layers/roundcube/roundcubemail/latest-fpm-alpine/images/sha256-9098e0ffc0c9012ea079448439766944af7793936a022f8882320b8282761668?context=explore

contains crypto malware baked into the image.

it is not present in the previous 1.4.11 which this repo contains.
https://hub.docker.com/layers/roundcube/roundcubemail/1.4.11-fpm-alpine/images/sha256-eef9d3f21a44e442f609a39e5675348bfe16653695af1e5427837686c5e74737

added the the ps output of the running containers.

this is not a welcomed april fools joke. please remove infected version from dockerhub.

2021/04/01 - latest-fpm-alpine

/var/www/html # ps aux
PID   USER     TIME  COMMAND
    1 root      0:06 php-fpm: master process (/usr/local/etc/php-fpm.conf)
   95 www-data  0:14 php-fpm: pool www
   96 www-data  0:14 php-fpm: pool www
   97 www-data  0:10 php-fpm: pool www
  230 www-data  0:18 /tmp/kinsing
  380 www-data  4d17 /tmp/kdevtmpfsi
  699 root      0:00 /bin/sh
  705 root      0:00 ps aux

1.4.11-fpm-alpine

/var/www/html # ps aux
PID   USER     TIME  COMMAND
    1 root      0:00 php-fpm: master process (/usr/local/etc/php-fpm.conf)
   73 www-data  0:00 php-fpm: pool www
   74 www-data  0:00 php-fpm: pool www
   75 root      0:00 /bin/sh
   82 root      0:00 ps aux

[thomascube]

I'm unable to verify your findings when running roundcube/roundcubemail:latest-fpm-alpine. What exactly is your indication that crypto malware is "baked into the image"? Maybe it's a mailcious injection in your Docker server and not the image itself. See this article for reference: https://www.zdnet.com/article/docker-servers-targeted-by-new-kinsing-malware-campaign/

[uriba107]

I'll check. Saw that article few hours ago. However it happened on two different systems. In two different countries. One without any incoming traffic (testing server).

I will try to replicate again on a third system.

I Was not able to Find anything suspicious in the docker layer info in dockerhub. But it is still wierd

[uriba107]

the more I look into it the more it looks like a php-fpm related attack. (it has also appeated on the 1.4.11-fpm-alpine instance I've been running). I've noticed that I've exposed php-fpm's 9000 port by accident, I've now edited my docker-compose to limit that access to localhost (as usually the case in direct OS installs).

I'll update the results and update the original issue to reflect the actual issue.

sorry for the false blame. I'll keep you posted

[pilere]

I also have been pawned by this malware and also have the port 9000 open but it's whats the example provided is suggesting :

https://github.com/roundcube/roundcubemail-docker/blob/master/examples/docker-compose-fpm.yaml

I also have a ufw firewall on the host, not allowing the port 9000 from outside ... so I don't get how they had get access through this ...

I am probably mistaking something but please, can you clarify for me ?

[navossoc]

@pilere You shouldn't leave your php-fpm port open to the world. You are allowing anyone to run some kind of PHP script on your server.

Docker and firewalls (on the host) don't play nicely, so you probably are not blocking that port at all. Try to check if the port is open outside your network with an external site, something like this: https://www.yougetsignal.com/tools/open-ports/

If you host everything on the same host, there is no need to expose the port 9000.

[pilere]

Hi, I understood that docker was playing with the iptables rules to make it easier for user to start ... at the end I was making 2 stupid errors, opening the port 9000 that should not and can stay container accessible only ... and 2 not checking the iptables rules directly ... I found that repo to help me out with this : https://github.com/chaifeng/ufw-docker

Thanks for your help !

[polarathene]

Docker and firewalls (on the host) don't play nicely

Just for context, both software manage firewalls but neither may be aware of the other also manipulating the routing rules. It just so happens that Docker adds rules that have higher precedence than UFW IIRC, but with firewalld they should be scoped a bit better I think? (I know of one issue with Docker, where firewalld prevented access from another device on the network, while UFW didn't)

---

As has already been established though, the examples are unwise when unnecessarily publishing ports to host network interfaces:

https://github.com/roundcube/roundcubemail-docker/blob/767d14a5e4fd4ce70b94c283327f0806b5963333/examples/docker-compose-fpm.yaml#L12-L13

If you actually needed that publishing, but only to be accessed via localhost (from the host), you could then use 127.0.0.1:9000:9000. That will restrict the binding to the loopback, preventing it from being published to other interfaces like one that can be accessed from untrusted clients.

If ports are only used internally between containers on the same network, they do not need to be published. Port publishing is just a mapping from host interface/IP + port to the containers IP (private subnet) and port.

---

Thus it'd be better to communicate to the reader of the config what ports the container might have of interest and what for, but discourage publishing (so they don't accidentally repeat the mistake that already has been committed).

If they need it for some other reason or testing that doesn't require connectivity external of the host, then bind only to loopback 127.0.0.1 like shown above.

[pabzm]

We actually should correct the examples to not publish port 9000