nginx真的存在文件类型解析漏洞吗？

Globalization

今天网上疯传一个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_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的服务器也有问题呢？？？？

网络寄生虫

shinko

我也手动编译的.为什么没有呢...估计是php-fpm版本不同吧..

zyypp

我手动编译的 存在这个问题 不过现在已经修改为403了

shinko

老实说,你们有没有测试过就修改补丁呢??

我测试过,我的安装包都没有事啊..难道我测试错了//

/dex.php

dex.jpg为探针,dex.php为不存在文件

msxcms

用了也没事

zyypp

apache 一般谁没事用 FastCGI 方式调用php呢

C小

问题是在Apache里面没有这个问题

fatso

偶用阿帕奇龟兔赛跑中..呵呵

zyypp

准确的说 这是 php的 path_info 的问题
而且暂时只表现在 FastCGI 模式下
而是用php的 FastCGI 模式最多的就是 nginx