【51CTO快譯】研究人員已經(jīng)在GNU C庫(kù)（即glibc）當(dāng)中發(fā)現(xiàn)一項(xiàng)高危安全漏洞，其可能導(dǎo)致現(xiàn)代Linux服務(wù)器面臨遠(yuǎn)程代碼執(zhí)行攻擊所帶來(lái)之風(fēng)險(xiǎn)。API Web服務(wù)與Rails、PHP乃至Python等高人氣Web框架也都因此受到影響。

 [[163088]]

此安全漏洞（CVE 2015-7547）為存在于glibc DNS客戶端解析器之getaddrinfo()函數(shù)中的基于堆棧緩沖區(qū)溢出問(wèn)題，且目前已經(jīng)得到修復(fù)。任何使用glibc 2.9以及更新版本（2.9版本于2008年5月發(fā)布）的用戶都有可能受到影響，這意味著幾乎全部glibc使用者都應(yīng)當(dāng)盡快安裝該補(bǔ)丁。紅帽企業(yè)Linux 5采用glibc 2.5，因此其不會(huì)受到該漏洞的影響; 不過(guò)紅帽企業(yè)Linux 6（使用glibc 2.12）、紅帽企業(yè)Linux 7（使用glibc 2.17）、Debian squeeze（使用glibc 2.11）、Debian wheezy（使用glibc 2.13）以及Debian jessie（使用glibc 2.19）則全部受到影響。

“必須認(rèn)真對(duì)待這一問(wèn)題，即盡快為glibc安裝修復(fù)補(bǔ)丁。該安全漏洞確實(shí)非常嚴(yán)重，”Open Crypto Audit項(xiàng)目主管兼安全研究員Kenneth White在自己的推文當(dāng)中寫道。

該漏洞最初由Ciena的Robert Holiday及其glibc項(xiàng)目小組所報(bào)告，時(shí)間點(diǎn)為2015年7月。在此之后，紅帽公司首席軟件工程師Carlos O’Donnell與紅帽產(chǎn)品安全團(tuán)隊(duì)成員Florian Weiner對(duì)該漏洞的影響做出評(píng)估并為其準(zhǔn)備了相應(yīng)補(bǔ)丁。谷歌公司研究員Fermin J. Serna與Kevin Stadmeyer亦獨(dú)立發(fā)現(xiàn)了報(bào)告中提及的該安全漏洞，并推出了一項(xiàng)針對(duì)該漏洞的概念驗(yàn)證利用方案。

“我們還沒(méi)有發(fā)現(xiàn)任何使用這項(xiàng)安全漏洞的實(shí)際攻擊活動(dòng)，”O’Donnell指出。

其中g(shù)etaddrinfo()函數(shù)通常被用于解析IP地址，在這種情況下，攻擊者可以利用該漏洞通過(guò)接入惡意DNS服務(wù)器實(shí)現(xiàn)對(duì)應(yīng)用程序及系統(tǒng)的控制權(quán)。利用這一安全漏洞進(jìn)行攻擊的可行途徑多種多樣，其中包括但不限于ssh、sudo以及curl，谷歌研究人員們解釋稱。

“使用該函數(shù)的軟件可能被攻擊者通過(guò)受控域名、攻擊者控制之DNS服務(wù)器或者中間人攻擊活動(dòng)所影響，”Serna與Stadmeyer在咨詢意見當(dāng)中寫道。

該安全漏洞會(huì)在系統(tǒng)從DNS服務(wù)器處接收到長(zhǎng)度過(guò)大的UDP或者TCP響應(yīng)結(jié)果時(shí)被觸發(fā)，具體為超過(guò)2048字節(jié)——而在此之前，攻擊者還需通過(guò)另一項(xiàng)響應(yīng)對(duì)該堆棧進(jìn)行覆蓋。要觸發(fā)這項(xiàng)緩沖區(qū)管理漏洞，目標(biāo)系統(tǒng)必須嘗試對(duì)攻擊者控制下的域名進(jìn)行DNS搜索。第一條接收到的響應(yīng)長(zhǎng)度為2048字節(jié)，這意味著其會(huì)占滿整個(gè)緩沖區(qū)、不留任何剩余空間。由于該緩沖區(qū)無(wú)法進(jìn)行復(fù)用，因此系統(tǒng)會(huì)建立一個(gè)新的緩沖區(qū)。但漏洞的存在導(dǎo)致原有緩沖區(qū)與新緩沖區(qū)同時(shí)存在，意味著整體緩沖區(qū)空間為65535.第二項(xiàng)響應(yīng)則迫使該系統(tǒng)重試這項(xiàng)查詢。第三項(xiàng)響應(yīng)包含有2048字節(jié)的有效響應(yīng)，但除此之外攻擊載荷仍有63487字節(jié)空間可以使用。

該漏洞之所以會(huì)發(fā)生，是因?yàn)楫?dāng)該查詢重新開始時(shí)，其指向的其實(shí)是擁有錯(cuò)誤容量的緩沖區(qū)，O’Donnell解釋道。“當(dāng)然還有其它辦法觸發(fā)這個(gè)緩沖區(qū)管理漏洞，但其需要對(duì)響應(yīng)計(jì)時(shí)進(jìn)行深入控制，并使用輪詢超時(shí)以通過(guò)兩次攻擊者響應(yīng)實(shí)現(xiàn)漏洞利用（而非三次），”O’Donnell表示。

紅帽公司的研究員們還得以利用該緩沖區(qū)溢出漏洞控制一項(xiàng)free()調(diào)用的執(zhí)行，并借此控制EIP注冊(cè)表。盡管他們并沒(méi)有嘗試進(jìn)一步利用該漏洞，但此次嘗試已經(jīng)證明了遠(yuǎn)程控制執(zhí)行的可能性。

“包絡(luò)分析結(jié)果顯示，攻擊者可以利用受控載荷編寫出格式正確的DNS響應(yīng)，從而突破DNS緩存結(jié)構(gòu)并借此接入到緩存背后的設(shè)備本體，”O’Donnell在其glibc項(xiàng)目群發(fā)郵件中寫道。

該漏洞產(chǎn)生的危害水平取決于系統(tǒng)現(xiàn)有緩沖區(qū)溢出漏洞應(yīng)對(duì)能力。遠(yuǎn)程代碼執(zhí)行可能“并不簡(jiǎn)單”，因?yàn)槠湫枰@過(guò)ASLR，谷歌公司的Serna解釋稱。管理員與開發(fā)人員如果無(wú)法立即安裝glibc補(bǔ)丁，也應(yīng)當(dāng)馬上采取臨時(shí)性應(yīng)對(duì)措施，從而防止?jié)撛诘墓粜袨椤Ｒ环N可行選項(xiàng)在于將本地DNS解析器所能接收的響應(yīng)長(zhǎng)度限制在1024字節(jié)。

對(duì)于這種長(zhǎng)度限制需要高度關(guān)注，因?yàn)槭褂肈NSSEC等先進(jìn)功能的系統(tǒng)可能需要接受超出正常長(zhǎng)度水平的UDP響應(yīng)。DNSSEC需要配合EDNSO，這項(xiàng)客戶端功能負(fù)責(zé)通知服務(wù)器其能夠接收長(zhǎng)度超過(guò)512字節(jié)的UDP響應(yīng)。因此，阻斷高長(zhǎng)度DNS響應(yīng)有可能會(huì)破壞EDNSO功能。“DNS解析可能因此發(fā)生失敗，或者出現(xiàn)顯著延遲，”SAN協(xié)會(huì)的Johannes B. Ullrich提醒稱。

管理員應(yīng)當(dāng)確保網(wǎng)絡(luò)之上的全部系統(tǒng)都采用特定解析器，同時(shí)阻斷一切出站DNS——除非其由已知解析器所生成。通過(guò)這種方式能夠限制漏洞被利用的可能性，而且“是種不錯(cuò)的處理辦法，”Ullrich指出。

與此同時(shí)，禁止雙A與AAA查詢可能也有助于緩解這種安全漏洞，而徹底禁用IPv6則無(wú)法禁用AAAA查詢或者預(yù)防漏洞問(wèn)題。阻斷IPv6的本地或者中間解析器并不能預(yù)防此類漏洞狀況，因?yàn)槁┒蠢幂d荷仍然能夠得到切實(shí)交付。“它屬于觸發(fā)該緩沖區(qū)管理漏洞的并發(fā)查詢，”O’Donnell寫道。

盡管相關(guān)補(bǔ)丁已經(jīng)正式推出，不過(guò)這場(chǎng)競(jìng)賽仍在進(jìn)行當(dāng)中，而且最終結(jié)果取決于哪方行動(dòng)更快——攻擊者還是防御者。“現(xiàn)在捕鼠貓已經(jīng)出籠，開發(fā)團(tuán)隊(duì)需要快速檢測(cè)其應(yīng)用程序是否處于風(fēng)險(xiǎn)當(dāng)中：但這項(xiàng)工作非常困難，因?yàn)間libc以深層方式集成在各類應(yīng)用當(dāng)中，”Black Duck軟件公司的Patrick Carey表示。修復(fù)的過(guò)程同樣相當(dāng)漫長(zhǎng)，特別對(duì)于那些移動(dòng)設(shè)備或者其它面向用戶的應(yīng)用程序而言。

需要指出的是，glibc庫(kù)屬于GNU項(xiàng)目所采用的標(biāo)準(zhǔn)C庫(kù)，而且被廣泛應(yīng)用于各類包含Linux內(nèi)核的GNU Linux及其它系統(tǒng)當(dāng)中。這也是最近幾個(gè)月來(lái)該庫(kù)曝出的第二個(gè)高危安全漏洞：就在去年，研究人員們發(fā)現(xiàn)glibc當(dāng)中存在著GHOST漏洞（CVE 2015-235）。

原文標(biāo)題：Patch now! Unix bug puts Linux systems at risk

【51CTO譯稿，合作站點(diǎn)轉(zhuǎn)載請(qǐng)注明原文譯者和出處為51CTO.com】