Bug #80385 [Com]: Response data preceded by post data
| From: | sizz00 at gmail dot com | Date: | Sat, 24 Sep 2022 17:48:34 +0000 |
| Subject: | Bug #80385 [Com]: Response data preceded by post data | ||
| References: | 1 | Groups: | php.bugs |
| Request: | Send a blank email to php-bugs+get-242461@lists.php.net to get a copy of this message | ||
Edit report at https://bugs.php.net/bug.php?id=80385&edit=1
ID: 80385
Comment by: sizz00 at gmail dot com
Reported by: 306503207 at qq dot com
Summary: Response data preceded by post data
Status: Re-Opened
Type: Bug
Package: FPM related
Operating System: CentOS 7.4
PHP Version: 7.2.34
Assigned To: bukka
Block user comment: N
Private report: N
New Comment:
Same issue on php 8.1.
But, this is not a bug, as noted bukka@php.net earlier.
After restricting connections for php-frm, the problem went away.
Apparently, someone connects from the outside and changes the parameters.
See file etc/php-fpm.d/zz-docker.conf or etc/php-fpm.d/www-docker.conf. Set parameter:
listen = 127.0.0.1:9000
or whatever you need.
And read the manual:
Because these settings are passed to php-fpm as fastcgi headers, php-fpm should not be bound to a
worldwide accessible address. Otherwise, anyone could alter the PHP configuration options.
https://www.php.net/manual/en/install.fpm.configuration.php
Previous Comments:
------------------------------------------------------------------------
[2022-01-22 03:53:25] mr dot liuyuwen at gmail dot com
When i turn off expose php-fpm port to internet, this bug gone.
so i think this bug product when you open the fpm port ,and you meet fastcgi attack. i will fake a
cgi request ,and then change you php.ini config. i will set auto_prepend_file = php://input.
------------------------------------------------------------------------
[2021-11-26 23:59:14] bukka@php.net
Just to repeat what was said before. This is not a vulnarebality but a feature that has been present
in PHP-FPM for some time. Personally I think it's not a really good thing to allow web servers
to change PHP ini through the FastCGI env variables and I plan to introduce an option to disable it.
But again it is on purpose and it is not a bug. There might be web server configs relaying on it so
we can't break it in minore release so the option would be an optional feature that you will
need to configure. We could maybe disable it by default in PHP 9.
Also I see in some comments confusion about the ports. It doesn't really matter what port
number PHP-FPM listen on. What matters is that this port is protected against external traffic (e.g.
by configuring firewall) and not exposed to anything else than your web server.
Please also note that even if we disable PHP_VALUE and PHP_ADMIN_VALUE, it's still not good
idea to allow external traffic to PHP-FPM. It wasn't designed for that and we would need to do
some additional review and hardening to be sure it's safe.
------------------------------------------------------------------------
[2021-11-26 14:09:13] dklugmann2 at yahoo dot com
Just a comment from our issue
This does appear to be 100% a hack attack exposing a php-fpm vulnerability
We updated the port in the php-fpm part of our yml docker file definition to be preceded with a
127.0.0.1 in front of the port name in the ports section thus restricting it to localhost access
only.
We also added a firewall with firewallcmd and limited access to only the very essential ports.
After that the issue has not reappeared.
Thanks
David
------------------------------------------------------------------------
[2021-11-23 23:37:05] dklugmann2 at yahoo dot com
Hi Jakub
I have emailed you our setup.
Many thanks for looking at this issue.
David
------------------------------------------------------------------------
[2021-11-23 21:34:12] bukka@php.net
Hi David,
It sounds good to me. If you could email me details how to recreate first, that would be awesome.
Ideally I would like to be able to recreate the issue locally on my computer because my setup will
make it easier for me to debug it. But if I'm not successful locally, then getting access to
the machine would be definitely useful. Mainly I would be then interested what is happening exactly
at time of the INI changes (e.g. having captured traffic of the port 9000 could be quite useful)
because after it changes, it's most likely too lite to see anything so in any case the steps to
recreate are very important.
Thanks
Jakub
------------------------------------------------------------------------
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