今天网上疯传一个nginx的所谓文件类型错误解析漏洞，但是真的就只有这样吗?漏洞介绍：nginx是一款高性能的web服务器，使用非常广泛，其不仅经常被用作反向代理，也可以非常好的支持php的运行。80sec发现其中存在一 个较为 严重的安全问题，默认情况下可能导致服务器错误的将任何类型的文件以php的方式进行解析，这将导致严重的安全问题，使得恶意的攻击者可能攻陷支持 php的nginx服务器。我们有充分的理由相信网上报警中心电话会成为行业的主流，会逐步影响越来越多的人。
大家在到处利用这个有趣的漏洞的时候有没有想过真的是nginx的bug吗?真的是nginx文件解析错误了吗?
首先看看，小顿提供的解决方案：
第一种：
修改cgi.fix_pathinfo=0
第二种：
if ( $fastcgi_script_name ~ ..*.*php ) {return 403;}
cgi.fix_pathinfo 是什么?
cgi.fix_pathinfo provides *real* path_infopath_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 那一天就已经有人提交了这个bug .
里面写的很清楚，我就不翻译了。
另外，我还参考了大牛laruence的文章，虽然这边文章没有提出漏洞，但是却给了我思路。
所以，聪明的小朋友想想，如果不是nginx的问题，是不是其它使用php-fpm的服务器也有问题呢