漏洞概要 关注数(1) 关注此漏洞
缺陷编号： WooYun-2011-01376
漏洞标题： 盛大网站漏洞修复方案不完整导致可能代码执行
相关厂商： 盛大网络
漏洞作者： BNE
提交时间： 2011-02-21
公开时间： 2011-03-23
漏洞类型： 命令执行
危害等级： 中
自评Rank： 10
漏洞状态： 厂商已经确认
漏洞来源： http://www.wooyun.org
Tags标签： nginx解析漏洞 安全意识不足 文件上传 逻辑缺陷 代码执行
漏洞详情
披露状态：
2011-02-21： 细节已通知厂商并且等待厂商处理中
2011-02-21： 厂商已经确认，细节仅向厂商公开
2011-03-03： 细节向核心白帽子及相关领域专家公开
2011-03-13： 细节向普通白帽子公开
2011-03-23： 细节向实习白帽子公开
2011-04-07： 细节向公众公开
简要描述：
盛大网站由于对漏洞理解有所偏差，没有按照实际情况进行漏洞修复，导致修复方案可以被绕过而失效。
详细说明：
之前盛大出过因为nginx+fastcgi-php造成的代码执行漏洞。后续盛大依照80sec的漏洞公告上的解决方案，对漏洞进行了简单修补:
if ( $fastcgi_script_name ~ \..*\/.*php ) {
return 403;
}
然而实际上，盛大的网站php fastcgi设置则不光是扩展名为php才能访问。
我们随便一个sdo的网站做一下实验：
http://forum.dev.sdo.com/robots.txt/s.
http://forum.dev.sdo.com/robots.txt/s.php
http://forum.dev.sdo.com/robots.txt/s.php5
以上连接均返回：
No input file specified.
而其余的链接则返回标准的http 404错误页面。
这说明只要扩展名为空、php、php5，都会被nginx传入后端的fastcgi进行处理，因此返回的是php-fastcgi的输出结果。
由此我们推测，盛大的php-fastcgi配置如下：
location ~ .*\.(php|php5)?$
{
#fastcgi_pass unix:/tmp/php-cgi.sock;
fastcgi_pass 127.0.0.1:9001;
fastcgi_index index.php;
include fcgi.conf;
}
如果厂家没有选择关闭cgi.fix_pathinfo的方式进行修补，而只是机械照搬80sec提供的临时性解决方案针对了url中包含php的链接进行了屏蔽，就可以通过以上几种链接方式绕过修复方案重现漏洞。
BTW:实际上这个问题不光是盛大出现，我估计网络上是有个教程之类的东东误导了大家，有很多人的php-fastcgi是配置成"location ~ .*\.(php|php5)?$"形式的。
漏洞证明：
经过测试，果然发现盛大创新园的blog存在问题配置，可以利用：
http://in.sdo.com/wp-content/plugins/tdo-mini-forms/tdomf-style-form.css/s.
修复方案：
使用cgi.fix_pathinfo=0的方式，一劳永逸。
或者根据自己网站的php-fastcgi设置，定制一个url屏蔽列表。
版权声明：转载请注明来源 BNE@乌云
漏洞回应
厂商回应：
危害等级：中
漏洞Rank：10
确认时间：2011-02-21
厂商回复：
多谢BNE提交漏洞信息！
最新状态：
暂无
漏洞评价：
对本漏洞信息进行评价，以更好的反馈信息的价值，包括信息客观性，内容是否完整以及是否具备学习价值
