# Possible widespread PHP configuration issue - security risk **URL:** \ **Category:** NGINX\ **Created:** [August 27, 2010, 5:23pm UTC](https://www.ruby-forum.com/t/possible-widespread-php-configuration-issue-security-risk/193999 "2010-08-27T17:23:05Z")\ **Posts on this page:** 16\ **Page:** 2
**Author:** ![ewildgoose](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/e/bcef8e/32.png) [@ewildgoose](https://www.ruby-forum.com/u/ewildgoose)\ **Post date:** [August 27, 2010, 7:51pm UTC](https://www.ruby-forum.com/t/possible-widespread-php-configuration-issue-security-risk/193999/21 "2010-08-27T19:51:49Z")
> I simply do not have time for the next several days. I’m literally > working day and night on an app that I need ready by Monday. Sure - I can update stuff. I only meant if you can spare some mins to contribute to a best efforts config. Our emails crossed - I will edit the media wiki entry to include an exclusion for the /images/ dir also. For me at least this is then “secure”. > Plus, I am probably the worst person to work on PHP issues as I firmly > believe PHP to be utter crap starting from its conception right down to > the last byte of its actual implementation. It tries my patience in > ways a toddler wired on espresso couldn’t. I hear you there… Allowing PHP apps on the server keeps me awake at night… As an aside, my solution has been to use linux-vservers for each php app. This was what led me to nginx to keep the memory usage of such a system low. It’s super easy to segment apps though and gives an extra amount of resilience to the installation Not relevant to our thread though… Cheers Ed W ---
**Author:** ![ewildgoose](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/e/bcef8e/32.png) [@ewildgoose](https://www.ruby-forum.com/u/ewildgoose)\ **Post date:** [August 27, 2010, 7:49pm UTC](https://www.ruby-forum.com/t/possible-widespread-php-configuration-issue-security-risk/193999/22 "2010-08-27T19:49:29Z")
On 27/08/2010 18:05, Cliff W. wrote: > Nevertheless, I’ve updated the MediaWiki entry. I’m still having problems getting to the wiki - no .js files are loading which is causing some wierd stuff to happen. However, my opinion is that just adding try\_files is only a partial fix. If some way is found to upload .php files (bad wikipedia config) or some other exploit is found that can bypass the try\_files then we still have an issue. My mediawiki config does this: ``` location ~ .*.php$ { include /etc/nginx/fastcgi_params; if ( $uri !~ "^/images/") { fastcgi_pass localhost:9000; } } ``` Others have already pointed out that we can do better than my IF. However, your try\_files, plus the explicit exclusion of the /images/ dir go a long way to secure mediawiki. Also I think the specific exclusion of the /images/ dir becomes quite self-documenting, whereas the try\_files is quite a subtle fix? Cheers Ed W ---
**Author:** ![ewildgoose](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/e/bcef8e/32.png) [@ewildgoose](https://www.ruby-forum.com/u/ewildgoose)\ **Post date:** [August 27, 2010, 7:53pm UTC](https://www.ruby-forum.com/t/possible-widespread-php-configuration-issue-security-risk/193999/23 "2010-08-27T19:53:35Z")
On Fri, Aug 27, 2010 at 06:48:12PM +0100, Ed W wrote: > However, your try\_files, plus the explicit exclusion of the /images/ > dir go a long way to secure mediawiki. Also I think the specific > exclusion of the /images/ dir becomes quite self-documenting, > whereas the try\_files is quite a subtle fix? Why don’t you just check if the file exists? I use something like that: location ~ .php$ { if (!-f $request\_filename) { return 404; } fastcgi\_pass unix:/var/run/php-fpm/php-fpm.sock; fastcgi\_param SCRIPT\_FILENAME $vpath/$fastcgi\_script\_name; include fastcgi\_params; } And it seems to fix the nginx issue. > Cheers > > Ed W > > * * * > > nginx mailing list > [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) > [mailman.nginx.org archive](http://nginx.org/mailman/listinfo/nginx) – ubitux ---
**Author:** ![ewildgoose](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/e/bcef8e/32.png) [@ewildgoose](https://www.ruby-forum.com/u/ewildgoose)\ **Post date:** [August 27, 2010, 8:05pm UTC](https://www.ruby-forum.com/t/possible-widespread-php-configuration-issue-security-risk/193999/24 "2010-08-27T20:05:17Z")
On Fri, 2010-08-27 at 19:52 +0200, ubitux wrote: > > then we still have an issue. > > Others have already pointed out that we can do better than my IF. > > location ~ .php$ { > > if (!-f $request\_filename) { > > return 404; > > } > > fastcgi\_pass unix:/var/run/php-fpm/php-fpm.sock; > > fastcgi\_param SCRIPT\_FILENAME $vpath/$fastcgi\_script\_name; > > include fastcgi\_params; > > } That’s exactly equivalent to the try\_files, except longer and using a deprecated feature. Cliff ---
**Author:** ![ewildgoose](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/e/bcef8e/32.png) [@ewildgoose](https://www.ruby-forum.com/u/ewildgoose)\ **Post date:** [August 27, 2010, 8:17pm UTC](https://www.ruby-forum.com/t/possible-widespread-php-configuration-issue-security-risk/193999/25 "2010-08-27T20:17:00Z")
On Fri, Aug 27, 2010 at 11:13 AM, Cliff W. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > It is subtle, but all fixes are, because the underlying vulnerability is > quite subtle. Â What user isn’t going to look at that and say to > themselves “why do I need this if statement?”. Â Just use the try\_files > and add a comment to its purpose. The caveat with try\_files is it means nginx has filesystem access to check the existence of the file and an additional stat call (or more) - it can be in the open file cache, modern systems it’s not a huge deal, etc, etc. But it won’t help if you’re fastcgi\_pass to a remote server that nginx does not have the same path to the file (or have access to the php file) at all. ---
**Author:** ![ewildgoose](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/e/bcef8e/32.png) [@ewildgoose](https://www.ruby-forum.com/u/ewildgoose)\ **Post date:** [August 27, 2010, 8:42pm UTC](https://www.ruby-forum.com/t/possible-widespread-php-configuration-issue-security-risk/193999/26 "2010-08-27T20:42:46Z")
On Fri, 2010-08-27 at 11:15 -0700, Michael S. wrote: > deal, etc, etc. > > But it won’t help if you’re fastcgi\_pass to a remote server that nginx > does not have the same path to the file (or have access to the php > file) at all. Good point. I do prefer your more general fix, although I’d like confirmation that it does fully address the issue (the whole split\_path thing is too weird for me to want to try to understand). Regards, Cliff ---
**Author:** ![ewildgoose](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/e/bcef8e/32.png) [@ewildgoose](https://www.ruby-forum.com/u/ewildgoose)\ **Post date:** [August 27, 2010, 8:14pm UTC](https://www.ruby-forum.com/t/possible-widespread-php-configuration-issue-security-risk/193999/27 "2010-08-27T20:14:05Z")
On Fri, 2010-08-27 at 18:48 +0100, Ed W wrote: > On 27/08/2010 18:05, Cliff W. wrote: > > > Nevertheless, I’ve updated the MediaWiki entry. > > I’m still having problems getting to the wiki - no .js files are loading > which is causing some wierd stuff to happen. I do not see any issues… does anyone else have a problem? > However, my opinion is that just adding try\_files is only a partial > fix. If some way is found to upload .php files (bad wikipedia config) I don’t think we should try to overcome people’s intentional configuration. Not only is it completely their fault if they go through the difficulty of enabling a feature that is off by default, but now we are attempting to impose our will on a user who has made a specific decision. This is always a bad road in software. > or some other exploit is found that can bypass the try\_files then we > still have an issue. Not going to worry about such speculative future issues. If such an issue arises it will need to be addressed as an Nginx patch, not a configuration option. > Others have already pointed out that we can do better than my IF. > However, your try\_files, plus the explicit exclusion of the /images/ dir > go a long way to secure mediawiki. Also I think the specific exclusion > of the /images/ dir becomes quite self-documenting, whereas the > try\_files is quite a subtle fix? It is subtle, but all fixes are, because the underlying vulnerability is quite subtle. What user isn’t going to look at that and say to themselves “why do I need this if statement?”. Just use the try\_files and add a comment to its purpose. Cliff ---
**Author:** ![ewildgoose](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/e/bcef8e/32.png) [@ewildgoose](https://www.ruby-forum.com/u/ewildgoose)\ **Post date:** [August 28, 2010, 12:35pm UTC](https://www.ruby-forum.com/t/possible-widespread-php-configuration-issue-security-risk/193999/28 "2010-08-28T12:35:02Z")
On 27/08/2010 16:45, Jim O. wrote: > It doesn’t work on the apps I mentioned. It simply won’t upload. > The apps you mentioned were vBulletin and IPB. I have done a little > more research on this and I believe I can smuggle in the PHP using jpeg > comments. The resulting file should pass all tests as a valid JPG, but > still be executable to the PHP interpreter… The point is: my expectation is that with a bit of wriggling it should be possible to find something which should get past your image upload checks, but your PHP interpreter will still happily process it. If your server is misconfigured to allow accidental execution of such files then I think you have a gaping hole in your security… Bottom line is to _completely disable_ execution of all untrusted files (variety of ways to do that of course) Personally I don’t believe in trusting _only_ to the upload filtering to secure a web application. There is simply too much subtlety here that a well crafted file should eventually be able to bypass… Ed W ---
**Author:** ![ewildgoose](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/e/bcef8e/32.png) [@ewildgoose](https://www.ruby-forum.com/u/ewildgoose)\ **Post date:** [August 28, 2010, 1:08pm UTC](https://www.ruby-forum.com/t/possible-widespread-php-configuration-issue-security-risk/193999/29 "2010-08-28T13:08:59Z")
Let’s stop debating and start with a clean fix. It sounds like this is all that is needed. Anyone want to verify? php config: cgi.fix\_pathinfo=0 then just make sure nginx splits the path info for you in case your app needs it with fastcgi\_split\_path\_info: location ~ .php$ { fastcgi\_pass 127.0.0.1:11000; include fastcgi\_params; fastcgi\_split\_path\_info ^(.+.php)(.\*)$; # just throw this in fastcgi\_params too, then! } Is this the right solution? Yes or no? ---
**Author:** ![ewildgoose](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/e/bcef8e/32.png) [@ewildgoose](https://www.ruby-forum.com/u/ewildgoose)\ **Post date:** [August 28, 2010, 1:41pm UTC](https://www.ruby-forum.com/t/possible-widespread-php-configuration-issue-security-risk/193999/30 "2010-08-28T13:41:45Z")
On Fri, Aug 27, 2010 at 11:06:00AM -0700, Michael S. wrote: > include fastcgi\_params; > fastcgi\_split\_path\_info ^(.+.php)(.\*)$; # just throw this in > fastcgi\_params too, then! > } > > Is this the right solution? Yes or no? - location ~ .php$ { - location ~ .php { BTW, in 0.8.x you may use location ~ ^(?.+.php)(?\.\*)$ { fastcgi\_pass 127.0.0.1:11000; fastcgi\_param SCRIPT\_FILENAME $script; fastcgi\_param PATH\_INFO $path\_info; include fastcgi\_params; } – Igor S. > **[Igor Sysoev](http://sysoev.ru/en/)** ---
**Author:** ![ewildgoose](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/e/bcef8e/32.png) [@ewildgoose](https://www.ruby-forum.com/u/ewildgoose)\ **Post date:** [August 28, 2010, 1:57pm UTC](https://www.ruby-forum.com/t/possible-widespread-php-configuration-issue-security-risk/193999/31 "2010-08-28T13:57:34Z")
On Fri, Aug 27, 2010 at 11:41:38AM -0700, Michael S. wrote: > On Fri, Aug 27, 2010 at 11:39 AM, Igor S. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > > > šlocation ~ ^(?.+.php)(?\.\*)$ { > > š šfastcgi\_pass 127.0.0.1:11000; > > š šfastcgi\_param š SCRIPT\_FILENAME š$script; > > Doesn’t this typically have the $document\_root$fastcgi\_script\_name - > so the full system path? You are right: š šfastcgi\_param š SCRIPT\_FILENAME š/path/to/files$script; or š šfastcgi\_param š SCRIPT\_FILENAME š$document\_root$script; > Thanks for the pointers, though. > > I will begin adopting this style once I check it quick and pushing it > on everyone I know… This way saves one regex execution. BTW, it’s better for perfomance and configuration maintenance reasons to isolate regex locaitons inside static ones as Maxim has shown: location / { š location ~ ^(?.+.php)(?\.\*)$ { … } … } location /dir1/ { … } location /dir2/ { š location ~ ^(?.+.php)(?\.\*)$ { … } … } – Igor S. > **[Igor Sysoev](http://sysoev.ru/en/)** ---
**Author:** ![ewildgoose](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/e/bcef8e/32.png) [@ewildgoose](https://www.ruby-forum.com/u/ewildgoose)\ **Post date:** [August 28, 2010, 1:44pm UTC](https://www.ruby-forum.com/t/possible-widespread-php-configuration-issue-security-risk/193999/32 "2010-08-28T13:44:41Z")
On Fri, Aug 27, 2010 at 11:39 AM, Igor S. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: >  location ~ ^(?.+.php)(?\.\*)$ { >   fastcgi\_pass 127.0.0.1:11000; >   fastcgi\_param  SCRIPT\_FILENAME  $script; Doesn’t this typically have the $document\_root$fastcgi\_script\_name - so the full system path? Thanks for the pointers, though. I will begin adopting this style once I check it quick and pushing it on everyone I know… ---
**Author:** ![ewildgoose](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/e/bcef8e/32.png) [@ewildgoose](https://www.ruby-forum.com/u/ewildgoose)\ **Post date:** [August 28, 2010, 2:09pm UTC](https://www.ruby-forum.com/t/possible-widespread-php-configuration-issue-security-risk/193999/33 "2010-08-28T14:09:16Z")
Initial testing shows: cgi.fix\_pathinfo = 0 and Igor’s suggestion: location ~ ^(?.+.php)(?\.\*)$ {   fastcgi\_pass 127.0.0.1:11000;   fastcgi\_param  SCRIPT\_FILENAME  $document\_root$script;   fastcgi\_param  PATH\_INFO     $path\_info;   include fastcgi\_params; } To be working properly. I need to check out PATH\_INFO using old style and new style, make sure it still reports the expected behavior for PHP scripts (PATH\_INFO, PHP\_SELF, all that jazz) The one thing I don’t like is now I have to hardcode that into each place, unless I defined the fastcgi\_pass location, and then just had a php.conf - then all of this could be done with a single line of config code. set $fastcgi\_pass = ‘127.0.0.1:11000’; include php.conf; php.conf would have this: location ~ ^(?.+.php)(?\.\*)$ {   fastcgi\_pass $fastcgi\_pass;   fastcgi\_param  SCRIPT\_FILENAME  $document\_root$script;   fastcgi\_param  PATH\_INFO     $path\_info;   include fastcgi\_params; } Would that be a workable solution Igor? Prior to this new style of PHP handling I used to only need two lines: fastcgi\_pass 127.0.0.1:11000; include fastcgi\_params; ---
**Author:** ![ewildgoose](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/e/bcef8e/32.png) [@ewildgoose](https://www.ruby-forum.com/u/ewildgoose)\ **Post date:** [August 28, 2010, 2:20pm UTC](https://www.ruby-forum.com/t/possible-widespread-php-configuration-issue-security-risk/193999/34 "2010-08-28T14:20:58Z")
On 27/08/2010 20:06, Michael S. wrote: > ``` > include fastcgi_params; > > ``` > > } > > To be working properly. I need to check out PATH\_INFO using old style > and new style, make sure it still reports the expected behavior for > PHP scripts (PATH\_INFO, PHP\_SELF, all that jazz) I will believe you that this works, but it seems incredibly subtle and I for one don’t quite understand why it’s working? My point is only that we need to document how/why this is the solution or users will deviate (innocently) and re-introduce the problem Please, please also lets have the final solution also include an example of how to efficiently _exclude_ a certain directory. A good proportion of apps that I have seen, ship with example Apache configurations that do exactly this. The suggestion was adding an excluded location: ``` location ^~/images/ { # just handle as static, don't consult regexps } ``` However, the issue I see here is that the user then needs to specifically configure how that location should be handled, rather than it being an _exclusion_ to the original location Can we work excluded locations into the regexp (negative lookahead supported?): location ~ ^(?!/images/)(?.+.php)(?\.\*)$ { The justification for excluding specific locations from the PHP interpretor is that _most_ applications don’t encourage uploaded executable cgi scripts and better apps are going to ship with a recommendation to disable script execution in the upload directory. Actually the situation is worse on Apache because there are so many ways to trick the interpreter to run files. However, it’s seems to be such standard practice on Apache that it seems prudent to include it in our standardised solution? Lots of justifications for this via google: > **[Google Search](http://www.google.co.uk/search?hl=en&q=disable+php+script+execution+upload)** Someone argued that this might be _wanted_ by the application… (Some apps _wants_ users to upload .php files which should then be executable…!!!). I claim that it will be a serious minority of applications desire this, and the vast majority will want uploaded files to be non executable (regardless of extension) Can we please, please, please try and make sure the recommended configuration includes examples of specifically _excluding_ locations not expected to contain executable scripts… My proposal above… Ed W ---
**Author:** ![ewildgoose](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/e/bcef8e/32.png) [@ewildgoose](https://www.ruby-forum.com/u/ewildgoose)\ **Post date:** [August 28, 2010, 2:25pm UTC](https://www.ruby-forum.com/t/possible-widespread-php-configuration-issue-security-risk/193999/35 "2010-08-28T14:25:04Z")
On Sat, Aug 28, 2010 at 3:14 AM, Ed W [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > I will believe you that this works, but it seems incredibly subtle and I for > one don’t quite understand why it’s working? > > My point is only that we need to document how/why this is the solution or > users will deviate (innocently) and re-introduce the problem It is a bit more complex to drop in and not as “straightforward” as one might hope. At the moment I have this working: main nginx.conf in a server {} block: set $fastcgi 127.0.0.1:11000; include confs/php.conf; root@local:/etc/nginx# cat confs/php.conf location ~ ^(?.+.php)(?\.\*)$ { fastcgi\_buffers 16 8k; fastcgi\_buffer\_size 8k; fastcgi\_busy\_buffers\_size 16k; fastcgi\_ignore\_client\_abort on; fastcgi\_index index.php; fastcgi\_intercept\_errors on; fastcgi\_param CONTENT\_LENGTH $content\_length; fastcgi\_param CONTENT\_TYPE $content\_type; fastcgi\_param DOCUMENT\_ROOT $document\_root; fastcgi\_param DOCUMENT\_URI $document\_uri; fastcgi\_param GATEWAY\_INTERFACE CGI/1.1; fastcgi\_param QUERY\_STRING $query\_string; fastcgi\_param PATH\_INFO $path\_info; fastcgi\_param REDIRECT\_STATUS 200; fastcgi\_param REMOTE\_ADDR $remote\_addr; fastcgi\_param REMOTE\_PORT $remote\_port; fastcgi\_param REQUEST\_METHOD $request\_method; fastcgi\_param REQUEST\_URI $request\_uri; fastcgi\_param SCRIPT\_FILENAME $document\_root$script; fastcgi\_param SCRIPT\_NAME $fastcgi\_script\_name; fastcgi\_param SERVER\_ADDR $server\_addr; fastcgi\_param SERVER\_NAME $http\_host; fastcgi\_param SERVER\_PORT $server\_port; fastcgi\_param SERVER\_PROTOCOL $server\_protocol; fastcgi\_param SERVER\_SOFTWARE nginx/$nginx\_version; fastcgi\_pass $fastcgi; } Now, it looks like $\_SERVER[‘PATH\_INFO’] is never filled in unless you have /foo.php/somethingafterit With cgi.fix\_pathinfo=1, PATH\_INFO = “/foo.php/somethingafterit” With cgi.fix\_pathinfo=0, PATH\_INFO = “/somethingafterit” Otherwise, PATH\_INFO is empty if there is nothing after the .php. PHP\_SELF is empty using the new style approach to the nginx config block. Using the old style, $\_SERVER[‘PHP\_SELF’] works; I tried setting a fastcgi\_param for it, but it did not take. It seems like this is derived internally in PHP and not able to be overridden. A lot of things reference PHP\_SELF, so this could introduce an issue. It’s late, but my quick tests show a glaring caveat with that. ---
**Author:** ![ewildgoose](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/e/bcef8e/32.png) [@ewildgoose](https://www.ruby-forum.com/u/ewildgoose)\ **Post date:** [August 30, 2010, 6:47pm UTC](https://www.ruby-forum.com/t/possible-widespread-php-configuration-issue-security-risk/193999/36 "2010-08-30T18:47:14Z")
All I’m reading here is reiterations of the previous discussion and language elites-ism . This is an extremely old issue, the opinion last time was that this is not something that should be fixed in Nginx. Nginx is a reverse proxy and there may be very valid cases where allowing such URIs make sense. The _real_ solution is to fix the php pathinfo setting, it’s archaic and shouldn’t be used unless absolutely necessary. That said, I did look around a bit on the wiki and it wasn’t covered overly much, about the only place was in my Nginx primer post so I’ll go ahead and add a section on the pitfalls page that details the issue. Posted at Nginx Forum: > **[Re: Possible widespread PHP configuration issue - security risk](https://forum.nginx.org/read.php?2,124297,125274#msg-125274)** > > Look, not had a lot of success raising this quietly. The Nginx wiki has a number of very insecure PHP configuration suggestions. Anyone using these example configurations should immediately review their configuration and ensure that they aren't... [Previous page](https://www.ruby-forum.com/t/possible-widespread-php-configuration-issue-security-risk/193999.md?page=1)