Edit report at https://bugs.php.net/bug.php?id=80385&edit=1
ID: 80385
Comment by: en3py at hotmail 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:
The service is binded to 0.0.0.0 but it allows only connections from the monitoring server
(firewalled + access list).
The issue happens even if the service is binded on 127.0.0.1 and you make the call from the same
server.
Previous Comments:
------------------------------------------------------------------------
[2021-03-21 19:42:05] bukka@php.net
> listen = 0.0.0.0:17302
Is this is a publicly accessible server or protect by VPN? Just wondering if something else could
hit it with PHP_ADMIN_VALUE. It's definitely not a good idea to open it to the world though.
Did you try to use listen.allowed_clients and white list the nagios? Just wondering if it's
because of something hits that with PHP_ADMIN_VALUE or there's another issue?
------------------------------------------------------------------------
[2021-03-19 17:40:47] en3py at hotmail dot com
Found the issue and full procedure to reproduce the problem.
We checked this behavior on:
- PHP 7.2.34
- PHP 7.3.26
We were using a Nagios control process to see if the FPM daemon was working, every 15 seconds it
made a POST call to the /status entry point of each context.
listen = 0.0.0.0:17302
pm.status_path = /status
1. Service started: the PHP-FPM worker works properly without any issue. POST requests were
correctly handled, data was not altered.
2. The Nagios control queried the /status page. This was the response:
[root@mon01 hosts]# /opt/nagios/libexec/check_fpm -p 17302 staging.eu.rightschain.co
"/status"
OK: PHP/7.3.26, pool [poolname] active processes 1 idle processes 1 started on 19/Mar/2021:17:31:45
+0000
3. The behavior of the two directives changed (in the phpinfo() output, not the configuration file)
FROM:
allow_url_include Off
auto_prepend_file None
TO:
allow_url_include On
auto_prepend_file php://input
And flapped between the two values resulting in an unstable behavior.
4. Restart the PHP-FPM process, and repeat from step 1. Occurs 100% of the times.
We disabled the /status page and binded the worker to 127.0.0.1 and changed monitoring process. The
issue disappeared from all monitored hosts.
For the record, this is the check we were using for the FastCGI gateway:
https://github.com/wuyunfeng/Python-FastCGI-Client
Hope it may be of help for anyone out there.
Cheers
------------------------------------------------------------------------
[2021-03-19 17:13:23] en3py at hotmail dot com
We digged a bit more in the problem and got the following details.
As someone mentioned, the issue seems to reside in the auto_prepend_file directive of the file.
So here is how we did reproduce the problem:
The php.ini file had the following settings:
auto_prepend_file = ""
allow_url_fopen = Off
allow_url_include = 0
Note that even setting to "Off" the allow_url_include directive, in the phpinfo() output
it was still set to "On".
To reproduce the problem:
1. open the page with phpinfo() output. In Core section you should see:
allow_url_include Off
auto_prepend_file None
2. refresh the page after a couple of seconds. At some point you will see the values changing in the
phpinfo() output:
allow_url_include On
auto_prepend_file php://input
Thus it starts showing the POST data prepended to the output.
------------------------------------------------------------------------
[2021-03-19 10:13:35] en3py at hotmail dot com
Having the same issue on two different deployments:
CentOS 7.9
CentOS 8.3
The problem does not appear on a CentOS 7.3
PHP compiled from source (7.2.34) with the following string:
./configure --prefix=/opt/php/7.2 \
--exec-prefix=/opt/php/7.2 \
--bindir=/opt/php/7.2/bin \
--sbindir=/opt/php/7.2/sbin \
--datadir=/opt/php/7.2/share \
--includedir=/opt/php/7.2/include \
--libdir=/opt/php/7.2/lib64 \
--localstatedir=/var \
--sharedstatedir=/var/lib \
--sysconfdir=/etc/php/7.2 \
--mandir=/usr/share/man \
--infodir=/usr/share/info \
--with-config-file-path=/etc/php/7.2 \
--with-config-file-scan-dir=/etc/php/7.2/conf.d \
--with-openssl-dir=/opt/openssl \
--disable-cgi --enable-ftp --enable-mbstring --enable-mysqlnd --with-curl --with-zlib \
--enable-fpm --with-fpm-user=apache --with-fpm-group=nobody --with-pdo-mysql \
--enable-zip --with-mysqli --enable-embedded-mysqli \
--with-openssl --with-ldap
FPM configuration for this context:
[xxx]
user = xxx
group = nobody
listen = 0.0.0.0:17202
pm = dynamic
pm.max_children = 5
pm.start_servers = 2
pm.min_spare_servers = 1
pm.max_spare_servers = 3
pm.process_idle_timeout = 10s;
pm.status_path = /status
access.log = /var/log/fpm-7.2-$pool.access.log
access.format = "%R %{HTTP_HOST}e - %u %t \"%m %r%Q%q\" %s %f %{mili}d %{kilo}M
%C%%"
slowlog = /var/log/php-7.2.$pool.slow.log
request_slowlog_timeout = 10s
request_slowlog_trace_depth = 20
php_admin_value[include_path] = ".:/opt/xxx/lib:/opt/php-7.2/lib64/php"
php_admin_flag[display_errors] = false
php_admin_value[session.name] = "xxx-staging"
php_admin_value[session.save_path] = "/opt/xxx/sessions"
php_admin_flag[session.auto_start] = true
From our experience this is what happens:
- the worker starts
- POST any form: everything seems right
- avoid making any call for 5-10 seconds
- POST THE SAME Form: response data is prepended to any output
The problem persists even if the target of the POST form is empty.
[19/Mar/2021:10:10:25 +0000] "POST /it/about/op-flag.php HTTP/1.1" 200 86 [omissis]
[19/Mar/2021:10:10:26 +0000] "POST /it/about/op-flag.php HTTP/1.1" 200 201 [omissis]
The first row (Apache HTTPD 2.4.46) has the correct output, while the second shows the prepended
results, so it really comes out from FPM.
We are still investigating the isse, whereas we have about 10 servers created last year with the
identical configuration and the problem seems not occurring...
------------------------------------------------------------------------
[2021-03-01 07:52:47] camalolo at gmail dot com
Having the same exact issue. Php 7.3.27 / Ubuntu 20.04
------------------------------------------------------------------------
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