May
21
| 引用 (357629214)在 2010.05.20 21:13 的发表： 最近，大楚网上总在评论武汉出租车司机的服务质量应该如何做好？总在说出租车司机今天有这样的拒载行为，明天那样的恶劣态度。可是武汉有一部分出租车司机还是不错的，为了生存，为了糊口，出租车司机真的也是不容易！ 现在就来谈谈大家所不知道的出租车管理部门背后的一些黑幕吧。前几年，客运出租汽车管理处（简称--客管处），为了司机的安全，给司机装上了GPS定位系统。凭借这个系统，一个位于出租车后挡风玻璃用来打广告的显示屏横空出世了，显示屏和GPS定位系统扯不上任何关系，只是他们用来打广告赚钱的一个工具。有了这个显示屏，司机的行车安全有了隐患，更别谈下雨天倒车了。当时很多司机质疑这个东西是否已经违反了道路交通安全法。可是因为强强联合，利益互享的原因，当时交管局认定了这个东西的合法性，于是每年的车辆年审我们可以顺利拿到PASS！这几年，在牺牲了司机安全行车的提前下，显示屏打广告赚的钱给他们带来了巨大的利润与好处。 今年交管局在我们出租车年审的时候，一口咬定要拆除这个显示屏，原因很简单，就是因为它违法了。不拆除，就不让年审。 我想告诉每一位武汉的市民朋友们： 车后显示频打广告赚的钱，客管处和交管局分得均匀，那么年审就是合法的。 现在他们利益分配不均，交管局就用法律赋予他们的权利，说这个显示频是违法的。不让年审。 客管处和交管局这两个单位，就因为一个小小的显示屏，把“合法”与“违法”在青天白日，朗朗乾坤下解读得如此鲜明！真让人心寒武汉的管理部门把法律的庄严，置于何处？ |
May
21
漏洞介绍：nginx是一款高性能的web服务器，使用非常广泛，其不仅经常被用作反向代理，也可以非常好的支持PHP的运行。80sec发现其中存在一个较为严重的安全问题，默认情况下可能导致服务器错误的将任何类型的文件以PHP的方式进行解析，这将导致严重的安全问题，使得恶意的攻击者可能攻陷支持php的nginx服务器。
漏洞分析：nginx默认以cgi的方式支持php的运行，譬如在配置文件当中可以以
| location ~ \.php$ { root html; fastcgi_pass 127.0.0.1:9000; fastcgi_index index.php; fastcgi_param SCRIPT_FILENAME /scripts$fastcgi_script_name; include fastcgi_params; } |
的方式支持对php的解析，location对请求进行选择的时候会使用URI环境变量进行选择，其中传递到后端Fastcgi的关键变量SCRIPT_FILENAME由nginx生成的$fastcgi_script_name决定，而通过分析可以看到$fastcgi_script_name是直接由URI环境变量控制的，这里就是产生问题的点。而为了较好的支持PATH_INFO的提取，在PHP的配置选项里存在cgi.fix_pathinfo选项，其目的是为了从SCRIPT_FILENAME里取出真正的脚本名。
那么假设存在一个http://www.80sec.com/80sec.jpg，我们以如下的方式去访问
| http://www.80sec.com/80sec.jpg/80sec.php |
将会得到一个URI
| /80sec.jpg/80sec.php |
经过location指令，该请求将会交给后端的fastcgi处理，nginx为其设置环境变量SCRIPT_FILENAME，内容为
| /scripts/80sec.jpg/80sec.php |
而在其他的webserver如lighttpd当中，我们发现其中的SCRIPT_FILENAME被正确的设置为
| /scripts/80sec.jpg |
所以不存在此问题。
后端的fastcgi在接受到该选项时，会根据fix_pathinfo配置决定是否对SCRIPT_FILENAME进行额外的处理，一般情况下如果不对fix_pathinfo进行设置将影响使用PATH_INFO进行路由选择的应用，所以该选项一般配置开启。Php通过该选项之后将查找其中真正的脚本文件名字，查找的方式也是查看文件是否存在，这个时候将分离出SCRIPT_FILENAME和PATH_INFO分别为
| /scripts/80sec.jpg和80sec.php |
最后，以/scripts/80sec.jpg作为此次请求需要执行的脚本，攻击者就可以实现让nginx以php来解析任何类型的文件了。
将会得到一个URI
| /80sec.jpg/80sec.php |
经过location指令，该请求将会交给后端的fastcgi处理，nginx为其设置环境变量SCRIPT_FILENAME，内容为
| /scripts/80sec.jpg/80sec.php |
而在其他的webserver如lighttpd当中，我们发现其中的SCRIPT_FILENAME被正确的设置为
| /scripts/80sec.jpg |
所以不存在此问题。
后端的fastcgi在接受到该选项时，会根据fix_pathinfo配置决定是否对SCRIPT_FILENAME进行额外的处理，一般情况下如果不对fix_pathinfo进行设置将影响使用PATH_INFO进行路由选择的应用，所以该选项一般配置开启。Php通过该选项之后将查找其中真正的脚本文件名字，查找的方式也是查看文件是否存在，这个时候将分离出SCRIPT_FILENAME和PATH_INFO分别为
| /scripts/80sec.jpg和80sec.php |
最后，以/scripts/80sec.jpg作为此次请求需要执行的脚本，攻击者就可以实现让nginx以php来解析任何类型的文件了。
POC： 访问一个nginx来支持php的站点，在一个任何资源的文件如robots.txt后面加上/80sec.php，这个时候你可以看到如下的区别：
访问http://www.80sec.com/robots.txt
| HTTP/1.1 200 OK Server: nginx/0.6.32 Date: Thu, 20 May 2010 10:05:30 GMT Content-Type: text/plain Content-Length: 18 Last-Modified: Thu, 20 May 2010 06:26:34 GMT Connection: keep-alive Keep-Alive: timeout=20 Accept-Ranges: bytes |
访问访问http://www.80sec.com/robots.txt/80sec.php
| HTTP/1.1 200 OK Server: nginx/0.6.32 Date: Thu, 20 May 2010 10:06:49 GMT Content-Type: text/html Transfer-Encoding: chunked Connection: keep-alive Keep-Alive: timeout=20 X-Powered-By: PHP/5.2.6 |
其中的Content-Type的变化说明了后端负责解析的变化，该站点就可能存在漏洞。
漏洞厂商：http://www.nginx.org
解决方案：
我们已经尝试联系官方，但是此前你可以通过以下的方式来减少损失
| 关闭cgi.fix_pathinfo为0 |
或者
| if ( $fastcgi_script_name ~ \..*\/.*php ) { return 403; } |
PS: 鸣谢laruence大牛在分析过程中给的帮助
