Nginx重大漏洞--------轉載的
Nginx重大漏洞--------轉載的
今天在找nginx 1.05的新功能時，無意中找到了這篇文章，本人沒有測試過，但是按照目前流行的「不管你信不信，反正我是信了」的理論，還是放出讓大家研究一下，避免損失。不是只有1.05才有這個問題，
轉載自 http://www.joey.ws/%E5%B9%BF%E8%80%8C%E5%91%8A%E4%B9%8B/nginx%E5%8F%91%E7%8E%B0%E9%87%8D%E5%A4%A7%E6%BC%8F%E6%B4%9E/
Nginx發現重大漏洞
發表於05.24, 2010
近日，80sec發現一個漏洞，這簡直讓所有安裝了nginx的網站猶如綁上定時炸彈，我試了一下，這個漏洞簡直超級超級嚴重，只要你的網站是nginx，並有上傳功能，那麼要秒掉閣下的網站，簡直不費吹灰之力。
我在我的cat.catcatgo.com分支上測試了一下，大家可以看看，例如我上傳了一個文件，名為logo.jpg，而事實上這個不是圖片，而是一段php代碼，本例是：
<?echo 「This is my PHP!」;?>
例如一個網站上有上傳頭像之類的功能，只需要通過這步騙過對方程序，例如，如果我的圖片上傳到根目錄：http://cat.catcatgo.com/logo.jpg，那麼只需要在後面添加一個/任何名字.php，例如：http://cat.catcatgo.com/logo.jpg/a.php，那麼就可以訪問到其中的php代碼。
本人的方法是在fcgi.conf中加入修改段：location ~* .*\.php($|/)
{
if ($request_filename ~* .*\.php$) {
set $is_path_info 『0′;
}
if (-e $request_filename) {
set $is_path_info 『1′;
}
if ($is_path_info ~ 『0′) {
return 403;
}cat.catcatgo.com例子擺放一周，下周修復這個支點漏洞。大家可以參詳一下。
以下是轉載文章：
漏洞介紹：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來解析任何類型的文件了。
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
解決方案：
我們已經嘗試聯繫官方，但是此前你可以通過以下的方式來減少損失
解決方案1：修改/usr/local/php/etc/php.ini將cgi.fix_pathinfo設為0 （註：前面可能有註釋符號; 需要刪除掉。），執行/usr/local/php/sbin/php-fpm restart重啟。
lnmp一鍵安裝包用戶可以直接執行命令：sed -i 』s/; cgi.fix_pathinfo=0/cgi.fix_pathinfo=0/g』 /usr/local/php/etc/php.ini 再執行：/usr/local/php/sbin/php-fpm restart重啟即可修復完成。
解決方 案2：為nginx虛擬主機添加如下內容：
if ( $fastcgi_script_name ~ \..*\/.*php ) {
return 403;
}
《解決方案》
謝謝分享了。這個我們在去年就已經修正了。不過還是比較感謝了。
