Nginx Parsing Vulnerability

Top security team in China 80sec on 5.20 Day 6 o'clock in the afternoon released a vulnerability notice on Nginx, due to the existence of the vulnerability, the use of nginx+php-built web site as long as allowed to upload images can be hacked, until 5.21 early morning, Nginx has not released a patch to fix the vulnerability.

According to Netcraft statistics, until April 2010, a total of 13 million servers worldwide running Nginx program, very conservative estimate, at least 6 million servers running Nginx and enabled PHP support, continue to conservative estimates, of which 1/ 6, that is, 1 million servers allow users to upload pictures

Because of the vulnerability of nginx, these 1 million servers may be uploaded by the method of the image of hackers easy to implant Trojan. The process of the Trojan is also very simple, is to change the Trojan into a picture upload is, because the harm is very big, do not say details. Interested please visit http://www.80sec.com/nginx-securit.html

Said so much, I think everyone on 80sec this top security team is more curious, vegetarian buns Brief introduction.

The 80SEC team consists of a group of young, energetic, energetic, passionate, and creative unmarried DotA men who work in information security at major Internet companies whose slogan is know it then hack it, vegetarian buns very much agree with this view: " As long as we are very familiar with a thing, it is possible to objectively find its shortcomings, and we can also find the merits of the thing. "

80sec means "80 port security", which is "web security", and since the team members are young people of Gen Y, we can also be understood as "Gen Y Security", in addition, because the SEC's pronunciation is se ke, we can also be understood as "Gen Y", "Gen Y" or " Our understanding of 80SEC is limited only by imagination.

The following describes their exploits, they have found IIS, IE, FireFox, Maxthon, the window of the world, Phpwind, Dedecms, QQ Mail, Quarkmail, extmail and other software vulnerabilities, visible fruitful.

Since introducing 80sec, we have to introduce another top security team that is very focused on web security 80vul, the team is also composed of Gen Y Boys shoes (90 after the pressure: p), they also found a large number of web app security vulnerabilities, such as IE, Gmail, WordPress, Phpwind, DISCUZ, MyBB and so on.

See here, presumably everyone in the heart have so little regret, that is why there is no Gen Y female hacker (I do not discriminate against false Niang, but I must explain not pseudo Niang), I also have the same regret.

Finally, a gossip, it is said that the hacker is already in action; security personnel, system administrators, action up, hurriedly repair the vulnerability; it's best not to get lucky, or the next hack might be your website. According to the 80SEC security bulletin description, the temporary repair method is as follows, can be 3 selected one.

1, set php.ini cgi.fix_pathinfo 0, restart PHP. Most convenient, but the effect of modifying the settings requires your own evaluation.

2, to the Nginx vhost configuration add the following content, restart Nginx. Vhost is also very convenient if you have fewer cases.

if ($fastcgi _script_name ~ \.. *\/.*php) {

return 403;

}

3, prohibit uploading directory to explain PHP program. Do not need to move webserver, if the vhost and the server is more, the short-term difficulty rises sharply; it is recommended to use the Vhost and the server less.

hily Original link: http://hily.me/blog/2010/05/nginx-php-configure-security-problem/
Copyright notice: Can be reproduced, reproduced must be in the form of hyperlinks to indicate the original source of the article and the author's information and copyright notice



Vulnerability Hazard Rating: devastating.
This vulnerability is strictly not caused by the vulnerability of Nginx and PHP itself, but by configuration. This is a common vulnerability in many of the configurations that I wrote earlier.

Simple detection method:
Open the Nginx + PHP server on any one of the pictures, such as:

If you add a string of/xxx.php (XXX is any character) after the image link, such as:

The image can also be accessed to indicate that there is a vulnerability in your configuration.

Vulnerability Analysis:
The following analysis of a very common Nginx configuration to explain the cause of the vulnerability:
server {
Listen 80;
server_name test.local;

Access_log/work/www/logs/test.access.log main;
Error_log/work/www/logs/test.error.log;

Location/{
Root/work/www/test;
Index index.html index.htm index.php;
}

Location ~ \.php$ {
Root/work/www/test;
Fastcgi_index index.php;
Fastcgi_param script_filename $document _root$fastcgi_script_name;
Include Fastcgi_params;
Fastcgi_pass Unix:/tmp/php-fpm.sock;
}
}

We create a new file Test.png in the/work/www/test/directory, which reads as follows:
Then, when accessed, the output is text content:
But when/xxx.php is added to the back, that is http://test.local/test.png/xxx.php, something terrible happens:
Array
(
[HOSTNAME] =
[PATH] =/usr/local/bin:/usr/bin:/bin
[TMP] =/tmp
[TMPDIR] =/tmp
[TEMP] =/tmp
[OSTYPE] =
[MACHTYPE] =
[Malloc_check_] = 2
[USER] = www
[HOME] =/home/www
[Fcgi_role] = RESPONDER
[Script_filename] =/work/www/test/test.png
[Query_string] =
[Request_method] = = GET
[Content_Type] =
[Content_length] =
[Script_name] =/test.png/xxx.php
[Request_uri] =/test.png/xxx.php
[Document_uri] =/test.png/xxx.php
[Document_root] =/work/www/test
[Server_protocol] = http/1.1
[Gateway_interface] = cgi/1.1
[Server_software] = nginx/0.7.62
[REMOTE_ADDR] = 192.168.1.163
[Remote_port] = 4080
[SERVER_ADDR] = 192.168.1.12
[Server_port] = 80
[SERVER_NAME] = test.local
[Redirect_status] = 200
[Http_accept] = Image/gif, Image/x-xbitmap, Image/jpeg, Image/pjpeg, Application/x-shockwave-flash, application/ QVOD, Application/qvod, Application/x-ms-application, APPLICATION/X-MS-XBAP, Application/vnd.ms-xpsdocument, Application/xaml+xml, Application/vnd.ms-excel, Application/vnd.ms-powerpoint, Application/msword, */*
[Http_accept_language] = ZH-CN
[Http_accept_encoding] = gzip, deflate
[Http_user_agent] = mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; Qqpinyin 689; Qqdownload 627; mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1);. NET CLR 2.0.50727;. NET CLR 3.0.4506.2152;. NET CLR 3.5.30729; infopath.2; TheWorld)
[Http_host] = test.local
[Http_connection] = keep-alive
[Orig_script_filename] =/work/www/test/test.png/xxx.php
[Path_translated] =/work/www/test
[Php_self] =/test.png/xxx.php
[Request_time] = 1274125615
)
In the environment variables, the Script_filename is passed by Nginx:
Fastcgi_param script_filename $document _root$fastcgi_script_name;
$FASTCGI _script_name Variable Description please refer to:
Http://wiki.nginx.org/NginxHttpFcgiModule

The value of Nginx passed to PHP is/work/www/test/test.png/xxx.php, which is the value of Orig_script_filename in $_server, but script_filename in $_server/wo Rk/www/test/test.png.
The reason is that/work/www/test/test.png/xxx.php does not exist, and for these non-existent paths, PHP examines the files that exist in the path and treats the extra portions as path_info.
Here,/work/www/test/test.png was parsed by PHP as script_filename,/xxx.php was discarded after parsing to path_info by PHP, and therefore did not appear in $_server.

Workaround:
The workaround for this vulnerability is obvious: turn off the parsing described above.
This resolution can be set in the PHP configuration file, which is enabled by default. Here we need to turn it off:
; Cgi.fix_pathinfo provides *real* path_info/path_translated support for CGI. PHP ' s
; Previous behaviour is to set path_translated to Script_filename, and to not Grok
; What Path_info is. For more information in Path_info, see the CGI specs. Setting
; This to 1 would cause PHP CGI to fix it paths to conform to the spec. A setting
; of zero causes PHP to behave as before. Default is 1. You should fix your scripts
; To use Script_filename rather than path_translated.
; Http://php.net/cgi.fix-pathinfo
; cgi.fix_pathinfo=1
Cgi.fix_pathinfo=0
Where cgi.fix_pathinfo=0 is the new configuration line, which means that automatic path_info detection of PHP is turned off. When off, the configuration vulnerability can be eliminated.

A better solution?
The above scheme is not the most perfect, if you have previously been useful to cgi.fix_pathinfo this feature, the impact will be very large, such as closed, my Blog (Wordpress) Article URL directory form will have to use rewrite to achieve.
If you can set PHP to only parse. php as an extension of the file, then this problem will be more reasonable to resolve.
But I did not find the relevant settings, perhaps in the future should appear in the PHP-FPM configuration file?

Summarize:
This type of problem is largely unpredictable, but if the architecture is well designed, it does not affect security even if the problem exists. Here are the architectural security recommendations:
* As far as possible to separate the dynamic content, all static content exists in the static content server, static content server does not parse PHP, so that static files can never be parsed

Nginx Parsing Vulnerability