上月，glibc(GNU C Library)再曝安全漏洞——編號(hào)為CVE-2015-7547的緩沖區(qū)溢出漏洞，該漏洞影響大多數(shù)Linux服務(wù)器以及大量利用開源glibc搭建的網(wǎng)絡(luò)架構(gòu)和服務(wù)，如ssh, sudo, curl, PHP Rails 等。據(jù)谷歌安全團(tuán)隊(duì)分析，該漏洞位于glibc的DNS客戶端解析器，應(yīng)可繞過內(nèi)存防護(hù)技術(shù)，從而形成代碼執(zhí)行漏洞。雖然這不是glibc第一次曝出安全漏洞，但由于DNS屬于核心網(wǎng)絡(luò)技術(shù)且很多互聯(lián)網(wǎng)服務(wù)都依賴于它，再加上此漏洞出現(xiàn)在發(fā)行于2008年glibc2.9，應(yīng)用于眾多Linux發(fā)行版本中，所以此漏洞的影響范圍非常廣泛。

　　實(shí)際上早在去年7月，glibc的維護(hù)人員就已經(jīng)發(fā)現(xiàn)了這個(gè)問題，但當(dāng)時(shí)這個(gè)編程上的問題被嚴(yán)重低估，后來谷歌的安全人員偶然發(fā)現(xiàn)了這個(gè)bug，在研究的過程中發(fā)現(xiàn)紅帽的兩位研究人員Florian Weimer 和 O"Donell也正在分析這個(gè)問題，但由于問題的嚴(yán)重性，兩人并未公布相關(guān)信息，只是在私下進(jìn)行研究。兩個(gè)團(tuán)隊(duì)最終于2016年1月6日開始合作，共同修復(fù)這些源代碼，合力開發(fā)了補(bǔ)丁更新。

　　漏洞影響

　　glibc是GNU發(fā)布的libc庫，它是Linux系統(tǒng)中最底層的API，幾乎其它運(yùn)行庫都會(huì)依賴于glibc。glibc組件包含了大量標(biāo)準(zhǔn)庫，這些標(biāo)準(zhǔn)庫會(huì)被眾多的程序調(diào)用。其中 libresolv庫用來實(shí)現(xiàn)主機(jī)名與IP地址之間轉(zhuǎn)換的功能。作為glibc包含的組件之一，nss_dns模塊通過libresolv庫進(jìn)行DNS查詢，從而實(shí)現(xiàn)Name Service Switch(NSS)服務(wù)。發(fā)現(xiàn)這個(gè)漏洞的谷歌研究人員解釋，glibc通過alloca()函數(shù)在堆棧中保有2048字節(jié)。如果響應(yīng)大于2048字節(jié)，就會(huì)從堆分配一個(gè)新的緩沖區(qū)，在某些情況下，會(huì)造成堆棧緩沖之間的不匹配，最后的結(jié)果就是，堆棧緩沖將被用于存儲(chǔ)DNS響應(yīng)，即使響應(yīng)包大小超過了堆棧緩沖，該行為導(dǎo)致堆棧緩沖的溢出。Libresolv庫中的代碼在執(zhí)行A/AAAA 雙重DNS查詢時(shí)會(huì)調(diào)用getaddrinfo庫函數(shù)(處理域名到地址、服務(wù)到端口的轉(zhuǎn)換)。遠(yuǎn)程攻擊者可以通過創(chuàng)建特殊的DNS響應(yīng)，如利用惡意域名服務(wù)器或中間人等，造成應(yīng)用程序乃至系統(tǒng)崩潰，或進(jìn)行遠(yuǎn)程代碼執(zhí)行，甚至取得root權(quán)限，調(diào)用函數(shù)send_dg(UDP查詢)和send_vc(TCP查詢)時(shí)會(huì)觸發(fā)此緩沖區(qū)溢出。

　　從對(duì)此漏洞的分析可以看出，承擔(dān)眾多互聯(lián)網(wǎng)服務(wù)基礎(chǔ)功能的DNS又一次成為了被攻擊者利用的工具。盡管目前還沒有證據(jù)表明已經(jīng)有攻擊者利用了此項(xiàng)漏洞，但為了系統(tǒng)安全考慮，在正式的補(bǔ)丁出來之前，不得不對(duì)glibc的DNS解析器做一些必要限制以減少漏洞利用的可能。如對(duì)于UDP查詢，可采取的措施有：丟棄大于512字節(jié)的UDP DNS數(shù)據(jù)包、設(shè)置本地解析器以丟棄不一致的響應(yīng)、避免A/AAAA雙重查詢，不使用EDNS0或DNSSEC等;對(duì)于TCP查詢，限制所有DNS響應(yīng)包大小在1024字節(jié)之內(nèi)。但進(jìn)行這些操作要慎之又慎，因?yàn)榇笮偷腄NS應(yīng)答雖不常見，但不一定是惡意的，上述措施在規(guī)避漏洞利用的同時(shí)，可能會(huì)影響正常的DNS解析。慶幸的是，雖然Linux操作系統(tǒng)還未更新，但glibc補(bǔ)丁已經(jīng)發(fā)布，用戶可以先打上glibc補(bǔ)丁阻斷黑客的利用可能。

　　專家建議

　　對(duì)于互聯(lián)網(wǎng)上最廣泛使用的DNS解析軟件BIND是否會(huì)受到此漏洞的影響，BIND的開發(fā)和維護(hù)機(jī)構(gòu)ISC(Internet Systems Consortium)認(rèn)為，由于BIND的核心——指定域名服務(wù)器守護(hù)進(jìn)程在進(jìn)行DNS解析時(shí)，雖然使用的也是getaddrinfo()函數(shù)，但調(diào)用的是BIND本身的代碼而不是系統(tǒng)庫中的，所以此漏洞對(duì)基于BIND的DNS解析軟件并無影響。但是一些實(shí)用程序或工具如dig、delv等，也隸屬于BIND包，在進(jìn)行DNS查詢后會(huì)調(diào)用系統(tǒng)庫中的 getaddrinfo()函數(shù)，所以盡管基于BIND的域名服務(wù)器風(fēng)險(xiǎn)很小，但I(xiàn)SC也強(qiáng)烈建議修復(fù)系統(tǒng)庫。

　　來自紅帽的分析表明，編寫成格式正確的、帶有攻擊者載荷的DNS響應(yīng)將會(huì)穿透DNS緩存層次結(jié)構(gòu)，允許攻擊者利用這些緩存背后的機(jī)器。針對(duì)于此，DNS安全專家Dan Kaminsky也有著自己的見解：如果一個(gè)DNS漏洞可以滲透DNS的層次結(jié)構(gòu)，那么問題已然升級(jí)，我們已經(jīng)處在另一種危險(xiǎn)之中，尤其是DNS應(yīng)用如此廣泛，一旦DNS查詢導(dǎo)致了惡意代碼執(zhí)行，那結(jié)果顯然是非常嚴(yán)重的。因此加固DNS緩存、加強(qiáng)架構(gòu)部署，發(fā)展和支持網(wǎng)絡(luò)基礎(chǔ)設(shè)施建設(shè)，也是迫在眉睫的事。

　　此漏洞也提醒我們，在DNS安全領(lǐng)域，攻擊手段越來越多樣化，攻擊層面也更為深入。為此，國內(nèi)領(lǐng)先的DNS解決方案提供商泰策也是非常擔(dān)憂的。由于DNS對(duì)互聯(lián)網(wǎng)業(yè)務(wù)的重要性，導(dǎo)致其成為許多網(wǎng)絡(luò)攻擊的目標(biāo)，而DNS系統(tǒng)本身的脆弱性也大大提高了這些攻擊的可能。此次涉及DNS的glibc漏洞，其發(fā)現(xiàn)用了八年，意味著給了攻擊者八年時(shí)間來發(fā)現(xiàn)和利用這個(gè)漏洞。而現(xiàn)在，補(bǔ)丁雖然給出，但必須重啟服務(wù)器，這對(duì)于一些業(yè)務(wù)來說也是破壞性的。所以這就需要互聯(lián)網(wǎng)安全人員在問題出現(xiàn)之前，建設(shè)更為安全的網(wǎng)絡(luò)平臺(tái)。為此，泰策也呼吁業(yè)界要加強(qiáng)DNS安全建設(shè)，對(duì)于關(guān)鍵應(yīng)用、關(guān)鍵部門所使用的DNS系統(tǒng)，采用更為可靠的商用解決方案，或者依賴專業(yè)技術(shù)服務(wù)團(tuán)隊(duì)的支撐，保證漏洞的及時(shí)修復(fù)和安全事件的及時(shí)響應(yīng)。