Securing php-fpm with nginx

[masterb56]

Found this one while searching how to secure php-fpm.

Consider a situation where remote users can upload their own pictures to the site. Lets say that an attacker uploads an image to http://www.bambookites.com/uploads/random.gif. What happens, given the server block above, if the attacker then browses to http://www.bambookites.com/uploads/random.gif/somefilename.php?

1. nginx will look at the URL, see that it ends in .php, and pass the path along to the PHP fastcgi handler.
2. PHP will look at the path, find the .gif file in the filesystem, and store /somefilename.php in $_SERVER['PATH_INFO'], executing the contents of the GIF as PHP.

Since GIFs and other image types can contain arbitrary content within them, it’s possible to craft a malicious image that contains valid PHP. That is how the attacker was able to compromise the server: he or she uploaded a malicious image containing PHP code to the site, then browsed to the file in a way that caused it to be parsed as PHP.
This issue was first discovered almost a year ago. The original report can be found in Chinese at http://www.80sec.com/nginx-securit.html. There is also a discussion about it on the nginx forums.
This issue can be mitigated in a number of ways, but there are downsides associated with each of the possibilities:

1. Set cgi.fix_pathinfo to false in php.ini (it’s set to true by default). This change appears to break any software that relies on PATH_INFO being set properly (eg: WordPress).
2. Add try_files $uri =404; to the location block in your nginx config. This only works when nginx and the php-fcgi workers are on the same physical server.
3. Add a new location block that tries to detect malicious URLs. Unfortunately, detecting based on the URL alone is impossible: files don’t necessarily need to have extensions (eg: README, INSTALL, etc).
4. Explicitly exclude upload directories using an if statement in your location block. The disadvantage here is the use of a blacklist: you have to keep updating your nginx configuration every time you install a new application that allows uploads.
5. Don’t store uploads on the same server as your PHP. The content is static anyway: serve it up from a separate (sub)domain. Of course, this is easier said than done: not all web applications make this easy to do.

Source: https://nealpoole.com/blog/2011/04/...trust-the-tutorials-check-your-configuration/

 

[LuDo8]

Fortunately, the vulnerable servers are easy do identify and fix. Example: http://example.com/path/to/file.png – a static object served by the vulnerable server. A crafted request to http://example.com/path/to/file.png/index.php for example should return 404. If it returns 500, then thing’s are bad. Worse though if it’s a 2xx or 3xx aka file.png = valid PHP.

So I go to my http://mywebsite.com/images/picture.png/index.php, and it gives me a bunch of codes, I'm guessing Nginx is vulnerable.

Whats the fix? The article wasn't exactly clear and simple.

 

[masterb56]

There's a few steps enumerated in the article. Try cgi.fix_pathinfo to php.ini fix he stated.

Anyway here's another one, looks like the EPEL nginx default installation is also vulnerable, so watch out :O Secure your nginx's! :P

The attack itself is simple: a malicious user who makes a request to http://example.com/file.ext%00.php causes file.ext to be parsed as PHP. If an attacker can control the contents of a file served up by nginx (ie: using an avatar upload form) the result is arbitrary code execution. This vulnerability can not be mitigated by nginx configuration settings like try_files or PHP configuration settings like cgi.fix_pathinfo: the only defense is to upgrade to a newer version of nginx or to explicitly block potentially malicious requests to directories containing user-controlled content.

https://nealpoole.com/blog/2011/08/...ith-null-bytes-php-and-old-versions-of-nginx/

 

[LuDo8]

Some users posted they had an issue with the pathinfo fix messing up their wordpress urls..

I tried this solution:

location ~* \.(js|css|png|jpg|jpeg|gif|ico)$ {
expires 1y;
log_not_found off;
}

  location ~ \.php$ {
  include /etc/nginx/fastcgi_params;
fastcgi_index index.php;
    fastcgi_param SCRIPT_FILENAME /home/www/dubstepremix.org/public_html$fastcgi_script_name;
  if ($uri !~ "^/images/") {
    fastcgi_pass 127.0.0.1:9000;
  
}
    
  }
}

I added that to the end of my individual site Conf file. Hopefully thats right.

I did try http://mywebsite.com/images/picture.png/index.php, it now correctly gives the 404 Error.

EDIT: Just saw your 2nd post after posting this one, ...arggh now I have to check what version of Nginx I have an update it too lol. Thanks for bringing these things up!

After publishing my previous blog post on PHP, nginx configuration, and potential arbitrary code execution, I came across a separate null-byte injection vulnerability in older versions of nginx (0.5.*, 0.6.*, 0.7 <= 0.7.65, 0.8 <= 0.8.37). By taking advantage of this vulnerability, an attacker can cause a server that uses PHP-FastCGI to execute any publicly accessible file on the server as PHP.

I have version 1.02 of Nginx on PHP-FPM, I guess that should be okay?

 

[masterb56]

Doing try_files $uri =404 seem to work for me with wordpress. Put that one on both your static and php files. And yeah if you could update nginx to 1.0.5 latest stable version that would be great