php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #63965 php-fpm site-specific settings go global
Submitted: 2013-01-11 10:40 UTC Modified: 2017-10-24 07:45 UTC
Votes:12
Avg. Score:4.8 ± 0.6
Reproduced:12 of 12 (100.0%)
Same Version:0 (0.0%)
Same OS:1 (8.3%)
From: markku dot niskanen at gmail dot com Assigned:
Status: Open Package: FPM related
PHP Version: 5.3.20 OS: Centos 6.2
Private report: No CVE-ID: None
 [2013-01-11 10:40 UTC] markku dot niskanen at gmail dot com
Description:
------------
# this is an nginx configuration for *.thiscustomer.com
# it should ONLY affect *.thiscustomer.com, no other domains
server {
server_name .thiscustomer.com;
#... normal stuff removed ...
location ~ \.php$ {
# now set  for THIS site
fastcgi_param PHP_VALUE 
"auto_prepend_file=/home/thiscustomer/lib/modules/ThisModule.class.php";
# ..other normal stuff from this on...
}
}


Test script:
---------------
Now first simply go any other site, say "www.thatcustomer.com" on the same server and everything works fine. 

Then go to "www.thiscustomer.com" (the example site) and everything works fine.

Then again go to "www.thatcustomer.com" and you will see that you will have an "open_basedir restriction", PHP trying to load file (prepending) /home/thiscustomer/lib/modules/ThisModule.class.php

So the auto_prepend_file value is changed GLOBALLY and permanently until some other domain changes it again. The same goes for ANY PHP_VALUE or PHP_ADMIN_VALUE but this is the one that will definitely break all sites.

Tested in PHP 5.3.19 and 5.3.20, two different servers, two different operating systems (Centos 5.8 and Centos 6.2).


Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2013-01-11 10:41 UTC] markku dot niskanen at gmail dot com
The setup code got broken during upload but you should get the idea.
 [2013-04-19 10:42 UTC] steven dot hartland at multiplay dot co dot uk
This is a very nasty security risk, with settings applied to trusted hosts being 
leaked to other vhosts.

It essentially means that if PHP_VALUE or PHP_ADMIN_VALUE is used then every value 
set must then be explicitly set for every vhost otherwise the settings leak.

This will also cause random behaviour dependent on request order.

This should be reclassified as security and FPM module
 [2013-04-30 18:11 UTC] stas@php.net
-Assigned To: +Assigned To: fat
 [2013-04-30 18:11 UTC] stas@php.net
-Package: PHP options/info functions +Package: FPM related
 [2013-05-20 14:22 UTC] 63965 dot phpbug at tomvalentine dot net
The problem with this is that when setting a value through fastcgi_param PHP_ADMIN_VAlUE (or PHP_VALUE) is that when php-fpm receives this value it is applied only to the child process that receives the request.

E.g. you have a pool of 5 processes, only one of thoses processes gets the value when the request is passed to it. When the child process is restarted (after max requests or max time) it loses the PHP_ADMIN_VALUE.

The side effect of this is some unpredictability as by requesting info.php from another server block, depending on which child process serves out info.php, you may get different results.

PHP-FPM also has rubbish security as any FCGI client can pass requests to it by default. E.g. nginx, php/python/perl scripts

You can sometimes limit who can access the php-fpm server by:
- If running as a unix domain socket, set listen.owner & listen.group to the user and group of the webserver which will not work if php-fpm and webserver are running as the same user and group. And set listen.mode to 0600 so that only the specified user can connect to it (renders listen.group pointless)

However from fpm.conf "Many BSD-derived systems allow connections regardless of permissions."

- If php-fpm is listening as a TCP server then you have to use a firewall to limit the connections between FCGI client and PHP-FPM (even if it is through localhost)

Other similar bugs: 53611 & 54309
 [2013-05-20 14:29 UTC] 63965 dot phpbug at tomvalentine dot net
PS. I wrote up a test script to test the settings on my PHP server:
http://tomvalentine.net/misc/socket.php.txt
 [2013-11-19 17:11 UTC] andy at propcom dot co dot uk
This seems to be a duplicate of bug 53611
 [2015-07-24 20:20 UTC] butesa at freenet dot de
This is not only about vhosts. Consider the following Apache configuration:

AddHandler proxy:fcgi://localhost:9000 .php
<Directory "/var/www/test2/">
  SetEnv PHP_VALUE max_execution_time=1
</Directory>

If a php process handles a request for /var/www/test2/, it will remember the setting and apply it to other requests too. But with the config above, you obviously want to apply the setting only to this one directory.

I think the right thing do to is revert all PHP_VALUE changes after each script execution, so the php process has the original settings when it accepts the next request.
 [2017-10-24 07:45 UTC] kalle@php.net
-Status: Assigned +Status: Open -Assigned To: fat +Assigned To:
 [2023-07-07 06:18 UTC] Apsaraofdelhi at gmail dot com
I Am Apsara Sharma Living in Dehradun If you are looking for independent model girls for your fun and enjoyment then contact my website. visit for more at Dehradunescort.org
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Thu Nov 21 09:01:32 2024 UTC