Edit report at https://bugs.php.net/bug.php?id=80385&edit=1
ID: 80385
Updated by: bukka@php.net
Reported by: 306503207 at qq dot com
Summary: Response data preceded by post data
Status: Open
Type: Bug
Package: FPM related
Operating System: CentOS 7.4
PHP Version: 7.2.34
Block user comment: N
Private report: N
New Comment:
So this is specifically documented in https://www.php.net/manual/en/install.fpm.configuration.php
. See the "Example #2 set PHP settings in nginx.conf" and the warning below that
"php-fpm should not be bound to a worldwide accessible address". So if the FPM is publicly
available, it should at least have listen.allowed_clients set so only the server can connect to it.
This looks like the reason why this got reported (setting PHP_VALUE and PHP_ADMIN_VALUE) from the OP
comments. Does anyone see this behaviour when having fpm protected?
Also it's not the first time I'm seeing a report like this so I'm thinking to
introduce some options that would disallow this.
Previous Comments:
------------------------------------------------------------------------
[2020-12-09 11:28:22] shoebox at dnbradio dot com
This is not a fix to the bug report but this is how I am working around the issue. I'm now
using nginx with mod_security enabled (wodby/nginx has mod_security built-in), and I have my default
host and location on nginx pointing to a static html page rather than php so that the attacker
cannot access the php location without using a domain name defined in the nginx config. With the
previous configuration an attacker was able to hit php-fpm by just going to the ip address. I have
not seen the problem return, however I am unsure if nginx with mod_security defaults is still
vulnerable to the same exploit. Additional configuration and filters may need to be applied.
------------------------------------------------------------------------
[2020-12-03 23:42:02] requinix@php.net
Even if it isn't strictly the container at fault, even if it ends up being an issue with Docker
or Debian or something else, if the container on Debian reproduces then that's at least a
starting point to look into it further.
------------------------------------------------------------------------
[2020-12-03 20:25:46] maxime dot mazouth-laurol at hotmail dot fr
I would be glad to do so, but I can't...
The reason ? I have the exact same docker container (php7.2-fpm) on a remote debian server and
locally under ubuntu but :
* the problem appears on the debian server (Debian GNU/Linux 9.8 stretch)
* the problem does not appear on my ubuntu 18.04 local machine, so I cannot reproduce it..
Then, one could logically think that the root cause is not in the docker container itself.
But if I restart the docker container, the issue disappears for some time, so it is container
related.
------------------------------------------------------------------------
[2020-12-02 00:44:47] requinix@php.net
There are quite a few variables and moving parts here. Can someone upload/link to a small but
complete repro somewhere? Like with a Dockerfile or two, maybe docker-compose file, and test script?
------------------------------------------------------------------------
[2020-12-01 22:21:42] maxime dot mazouth-laurol at hotmail dot fr
Did someone find a solution for this issue ?
I have the same with php:7.2-fpm docker container named "engine" from now on.
Even if the POST data prepends the response, I keep getting none values from php.ini :
* linux command : docker-compose exec engine php -i | grep prepend
* output : auto_prepend_file => no value => no value
* linux command : docker-compose exec engine php -i | grep url_include
* output : allow_url_include => Off => Off
------------------------------------------------------------------------
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
https://bugs.php.net/bug.php?id=80385
--
Edit this bug report at https://bugs.php.net/bug.php?id=80385&edit=1