今天网上疯传一个Nginx的所谓文件类型错误解析漏洞，但是真的就只有这样吗？漏洞介绍：nginx是一款高性能的web服务器，使用非常广泛，其不仅经常被用作反向代理，也可以非常好的支持PHP的运行。80sec发现其中存在一 个较为 严重的安全问题，默认情况下可能导致服务器错误的将任何类型的文件以PHP的方式进行解析，这将导致严重的安全问题，使得恶意的攻击者可能攻陷支持 php的nginx服务器。
原文详细见：http://www.80sec.com/nginx-securit.html
大家在到处利用这个有趣的漏洞的时候有没有想过真的是Nginx的Bug吗？真的是Nginx文件解析错误了吗？
首先看看，小顿提供的解决 方案：
第一种：
cgi.fix_pathinfo provides *real* PATH_INFO/PATH_TRANSLATED support for CGI. PHP's previous behaviour was to set PATH_TRANSLATED to SCRIPT_FILENAME, and to not grok what PATH_INFO is. For more information on PATH_INFO, see the cgi specs. Setting this to 1 will cause PHP CGI to fix it's 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.
我 注意到三件事情：
1.两种方案的修改都是针对fastcgi做的
2.这个漏洞只提出针对Nginx+PHP CGI有效
3. 漏洞利用的最终后缀一定是.php，而不是输入任何后缀都被当作PHP执行
由上面三点我做出一个假设，这个并不是Nginx的漏洞，而是fastcgi或者php-fpm的bug。
接下来要做的就是漏洞重现。
我首先假设是Nginx版本的问题，所以我测试了以下版本，测试顺序是 nginx 0.7.32 nginx 0.8.34 nginx 0.6.32
因为80sec是个很有名的安全网站，所以我很坚信是我自己错了，所以当测试完0.7.32和 0.8.34都没有出现这个漏洞的时候，我差点下了一个武断的结论，0.7以下版本的Nginx才受此漏洞影响，但是当我测试完0.6.32之 后，我崩溃了，依然没有重现这个漏洞。看来，我上面的结论有可能成立～～
于是，我测试了三个版本的php-fpm, 0.6, 0.5.13, 0.5.10。 上面测试nginx不同版本时，我用的是0.6，没能重现漏洞，然后接下来两个版本 0.5.13，0.5.10都出现了这个漏洞。我比较了下不同版本php-fpm下的phpinfo();,发现php-fpm 0.6 没有 cgi.fix_pathinfo这个选项，即使在php.ini中做了设置也不会有这个选项值，而php-fpm 0.5版本下的phpinfo();有这个选项值。
所以我断定是php-fpm的问题。php-fpm 0.6中有可能禁用了cgi.fix_pathinfo这个选项，或者说修正了这个bug.
为了证实我的这个想法，我Google了一 下，发现在 2010-01-27 那一天就已经有人在bugs.php.net提交了这个Bug .
详见：http://bugs.php.net/bug.php?id=50852&edit=1， 里面写的很清楚，我就不翻译了。
另外，我还参考了大牛laruence的文章 http://www.laruence.com/2009/11/13/1138.html， 虽然这边文章没有提出漏洞，但是却给了我思路。
所以，聪明 的小朋友想想，如果不是Nginx的问题，是不是其它使用php-fpm的服务器也有问题呢？？？？
大家在到处利用这个有趣的漏洞的时候有没有想过真的是Nginx的Bug吗？真的是Nginx文件解析错误了吗？
首先看看，小顿提供的解决 方案：
第一种：
第 二种：修改cgi.fix_pathinfo=0
cgi.fix_pathinfo 是什么？if ( $fastcgi_script_name ~ ..*/.*php ) {
return 403;
}
cgi.fix_pathinfo provides *real* PATH_INFO/PATH_TRANSLATED support for CGI. PHP's previous behaviour was to set PATH_TRANSLATED to SCRIPT_FILENAME, and to not grok what PATH_INFO is. For more information on PATH_INFO, see the cgi specs. Setting this to 1 will cause PHP CGI to fix it's 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.
我 注意到三件事情：
1.两种方案的修改都是针对fastcgi做的
2.这个漏洞只提出针对Nginx+PHP CGI有效
3. 漏洞利用的最终后缀一定是.php，而不是输入任何后缀都被当作PHP执行
由上面三点我做出一个假设，这个并不是Nginx的漏洞，而是fastcgi或者php-fpm的bug。
接下来要做的就是漏洞重现。
我首先假设是Nginx版本的问题，所以我测试了以下版本，测试顺序是 nginx 0.7.32 nginx 0.8.34 nginx 0.6.32
因为80sec是个很有名的安全网站，所以我很坚信是我自己错了，所以当测试完0.7.32和 0.8.34都没有出现这个漏洞的时候，我差点下了一个武断的结论，0.7以下版本的Nginx才受此漏洞影响，但是当我测试完0.6.32之 后，我崩溃了，依然没有重现这个漏洞。看来，我上面的结论有可能成立～～
于是，我测试了三个版本的php-fpm, 0.6, 0.5.13, 0.5.10。 上面测试nginx不同版本时，我用的是0.6，没能重现漏洞，然后接下来两个版本 0.5.13，0.5.10都出现了这个漏洞。我比较了下不同版本php-fpm下的phpinfo();,发现php-fpm 0.6 没有 cgi.fix_pathinfo这个选项，即使在php.ini中做了设置也不会有这个选项值，而php-fpm 0.5版本下的phpinfo();有这个选项值。
所以我断定是php-fpm的问题。php-fpm 0.6中有可能禁用了cgi.fix_pathinfo这个选项，或者说修正了这个bug.
为了证实我的这个想法，我Google了一 下，发现在 2010-01-27 那一天就已经有人在bugs.php.net提交了这个Bug .
详见：http://bugs.php.net/bug.php?id=50852&edit=1， 里面写的很清楚，我就不翻译了。
另外，我还参考了大牛laruence的文章 http://www.laruence.com/2009/11/13/1138.html， 虽然这边文章没有提出漏洞，但是却给了我思路。
所以，聪明 的小朋友想想，如果不是Nginx的问题，是不是其它使用php-fpm的服务器也有问题呢？？？？