2014年10月2日 星期四

BASH ShellShock 漏洞分析


這回的 bash 漏洞很有趣,定義一個 script 函式竟然能夠被自動觸發執行。CVE-2014-6271 漏洞揭露後,經過數日,許多人不斷地在找尋可利用此漏洞的方法,試圖可以進行遠端入侵或本地提權等,也有不少人瘋狂找尋 bash 或其它 shell 的類似問題,當然各資安相關媒體或廠商也不斷 "提醒" 大家要盡快升級 bash,彷彿有了 bash 就會被入侵一般。

目前 shellshock wiki 描述及收集了詳細的資訊,這篇 BASH 代碼注入的安全漏洞 也針對漏洞作了詳細說明,以及 DevCore 的 Shaolin 寫的這篇。所以我打算針對漏洞成因,以及漏洞利用環境作探討。


漏洞原因


在 bash 的原始碼 variables.c 中可以看到 bash 在初始化環境變數時,會掃瞄環境變數中是否有函式定義,其函式定義的 keywords 為 "() {",見第 11 行。若有函式定義的字串,應該僅轉換為函式內容,不應該執行該函式,見第 21 行。


Patch 的方式可見 patch ,主要是導入兩個參數定義
+ #define SEVAL_FUNCDEF 0x080  /* only allow function definitions */
+ #define SEVAL_ONECMD 0x100  /* only allow a single command */



然後在原來呼叫 parse_and_execute() 的地方改用
parse_and_execute (temp_string, name, SEVAL_NONINT|SEVAL_NOHIST|SEVAL_FUNCDEF|SEVAL_ONECMD);

並且在 parse_and_execute() 裡再去檢查是否有 SEVAL_FUNCDEF|SEVAL_ONECMD。



遠端執行指令碼



想要利用這個 bash 漏洞,就要非常了解 Linux 的環境變數繼承關係。事實上,在 Unix 系統中以環境變數來傳遞參數或資料是很平常的事,因為環境變數是 key=value 格式,又具有行程間繼承的作用。

因此,要找到可利用的情況,首先要找尋一個網路服務程式,此程式會將網路上接收的資料或請求(Request)轉換為環境變數,若是網路服務程式再透過 execle()/execvpe()/execve() 或是 system()/popen() 來執行其它程式時,因為上述函式會繼承環境變數的關係,才有成功利用的機會。


以 httpd 為例,其實 httpd 並不會接收遠端傳來的環境變數,而是 httpd 在 mod_rewrite 模組執行時將 HTTP Request 中的欄位轉換填入對應的環境變數中,再經由 mod_cgi 模組執行 CGI 程式。所以 CGI 程式可以透過環境變數的方式取得 HTTP Request 所需要的內容。
例如,將 HTTP Request 中的 User-Agent 欄位的內容,轉換為環境變數為 HTTP_USER_AGENT 的內容,以便任何語言開發的 CGI 程式可以透過環境變數 HTTP_USER_AGENT 取得  User-Agent 欄位內容。


C 語言 CGI 範例



在此 C 語言的範例中,即便 system() 中執行的命令是固定,不可被 Command Injection,但透過 CVE-2014-6271,則可以執行任意命令,因為 system() 是透過 /bin/sh -c 來執行 /bin/hostname。

事實上,不只 C 語言開發的 CGI,任何語言開發的 CGI 程式透過 httpd mod_cgi 執行,都可能會被利用此漏洞。不過若是直接用 bash script 開發的 CGI 程式,則不需要再透過呼叫 system(),直接就可以利用此漏洞。


bash script 語言 CGI 範例


經過測試 mod_cgi 搭配各語言,發現 perl 和 ruby 在某些情況下無法利用此漏洞。原因是,
perl 和 ruby 在進行 system()/popen() 之類的呼叫時,會先經過最佳化,判斷是否只是執行外部程式而非真的 script 命令,只有是 script 命令才會透過 /bin/sh -c 來執行,否則會直接執行(execve)該外部程式。
例如 perl 語言中:

system ("/bin/env > /dev/null");
system("/bin/uname -a");

第一行的命令字串中因為有 > 重新導向輸出的符號,因此會透過 /bin/sh -c 來執行該命令,但是第二行的命令字串中,僅是直接執行 /bin/uname,因此並不會透過 /bin/sh -c 來執行該命令,也就不會造成漏洞利用。

下列是我在 CentOS 6.4 + Apache 2.2.15 測試了各語言版本 CGI 程式,搭配不同的環境,所測試的結果:

V: 可直接利用或透過 system()/popen() 利用
O: 在未最佳化執行的 system()/popen() 情況下可利用
X: 不可被利用
我建議 Linux 伺服器管理者優先將 Linux 伺服器作 bash 升級,並且將網站環境作分析,評估不再使用 mod_cgi 或 mod_fastcgi。另外也請將 Linux 作安全性強化,可參考 Kenduest Lee (小州)的 Security Enhanced Linux


另外一個例子是透過 DHCP 發送含執行代碼的封包,讓 Linux 的 dhclient 被利用此漏洞來入侵。從 Internet Systems Consortium DHCP Distribution Version 4.2.4 的原始碼來看,的確是 dhclient.c 會從 DHCP 封包中將參數值透過內建的 client_envadd() 轉換成環境變數,再經由 execve() 執行了 dhclient-script (bash script),所以當然也就中獎了。

下列兩道指令可用來檢測系統上的 dhclient 是否會被此漏洞影響,當然 patch bash 才是王道。

$ /sbin/dhclient - 2>&1 | grep "ISC"
This version of ISC DHCP is based on the release available
$ which dhclient-script
/sbin/dhclient-script

另一個漏洞 CVE-2014-7169


env X='() { (a)=>\' sh -c "echo date"; cat echo

這行環境變數的設定,會使得原來應該是 echo date,顯示 "date" 字串,變成執行 "date" 指令。從 bash 原始碼中可發現,在 shell_getc (y.tab.c) 讀取輸入字串遇到錯誤時會呼叫 reset_parser() (y.tab.c),然而控制字元讀取位置的 global 變數 int eol_ungetc_lookahead 卻沒有重置歸 0,修補方式請看 patch

所以 () { (a)=>\ 是用 = 字元故意製造錯誤,字元讀取位置因為沒被重設,還留在 > 字元,因此在讀取 "echo date" 後原本要執行 "echo" 變成了讀取 ">echo date",執行後結果變成執行 "date" 命令,將結果輸出至 "echo" 檔案中。

這個漏洞要利用的條件限制更多,而且不像 CVE-2014-6271 可以指定任何命令執行,而只能讓原本要執行的命令作改變,有點類似當年 Unix IFS 的問題。

結論

目前此漏洞仍然在發酵中,有些人找尋了特定 CGI 網站程式進行攻擊,也有人試圖找尋其它的相關漏洞,也許這漏洞真的有機會得到今年的 Pwnie Award 呢。



[References]
1. https://access.redhat.com/articles/1200223
2. https://securityblog.redhat.com/2014/09/26/frequently-asked-questions-about-the-shellshock-bash-flaws/
3. http://ftp.gnu.org/pub/gnu/bash/bash-3.2-patches/bash32-052
4. http://www.cnblogs.com/LittleHann/p/3992778.html
5. http://www.trendmicro.com/cloud-content/us/pdfs/security-intelligence/white-papers/wp-shellshock.pdf
6. http://jaxbot.me/articles/cases-where-bash-shellshock-is-safe-09-25-2014
7. http://security.stackexchange.com/questions/68448/where-is-bash-shellshock-vulnerability-in-source-code

沒有留言: