Bug #80385 [Com]: Response data preceded by post data

From: 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

« previous php.bugs (#242461) next »