0x00 背景

最近某安全公司發(fā)現(xiàn)的glibc gethostbyname buffer overflow漏洞，該漏洞被命名為ghost，其原因是glibc的Gethostbyname函數(shù)在處理傳入的畸形域名信息作解析時(shí)導(dǎo)致堆溢出，眾多網(wǎng)絡(luò)應(yīng)用依賴glibc模塊的將受到影響，現(xiàn)已經(jīng)確認(rèn)受影響的版本是glibc 2.2<=version<=2.17，但是在我們的安全研究人員在測(cè)試時(shí)觸發(fā)了另一個(gè)有意思的格式串漏洞，讓我們來(lái)看看具體過(guò)程。

0x01 分析細(xì)節(jié)

測(cè)試環(huán)境ubuntu glibc 2.12 python 2.6.6

當(dāng)我們的研究人員在執(zhí)行python如下代碼時(shí)發(fā)現(xiàn)程序崩潰

讓我們看看漏洞觸發(fā)流程，上gdb看看

通過(guò)查看異常信息點(diǎn)發(fā)現(xiàn)，異常發(fā)生在如下代碼處

在memcpy函數(shù)進(jìn)行內(nèi)存拷貝時(shí)出錯(cuò)

通過(guò)分析發(fā)現(xiàn)，rdx是拷貝長(zhǎng)度，rsi是源緩沖區(qū)，rdi是目的緩沖區(qū)，通過(guò)分析發(fā)現(xiàn)rsi是我們傳入的數(shù)據(jù)，而rdi這個(gè)地址不能訪問(wèn)，所以memcpy函數(shù)進(jìn)行拷貝操作時(shí)將會(huì)出現(xiàn)寫入目的地址空間失敗，通過(guò)分析發(fā)現(xiàn)這個(gè)地址未初始化，最終導(dǎo)致程序crash.

我們通過(guò)分析發(fā)現(xiàn)python語(yǔ)句

將會(huì)調(diào)用sscanf格式轉(zhuǎn)換字符串’0’*10000000成整形數(shù)據(jù)“%d.%d.%d.%d”，我們通過(guò)分析glibc里面的源代碼stdio-common/vfscanf.c發(fā)現(xiàn)，將會(huì)如下處理

關(guān)鍵問(wèn)題發(fā)生在宏ADDW，如下代碼是glibc 2.12

這里代碼的作用是把我們傳入的字串循環(huán)拷貝到棧上面去，alloca函數(shù)是開辟�？臻g，我們知道默認(rèn)情況下Linux的�？臻g是8MB，當(dāng)我們傳入的參數(shù)超長(zhǎng)時(shí)，會(huì)導(dǎo)致棧空間耗盡，導(dǎo)致內(nèi)存寫上溢，當(dāng)我們寫入不可預(yù)知的未映射的內(nèi)存時(shí)導(dǎo)致程序崩潰. 通過(guò)搜索發(fā)現(xiàn)這個(gè)格式串漏洞在2.15版被修復(fù)

補(bǔ)丁代碼如下:

補(bǔ)丁代碼的處理邏輯是把傳入的數(shù)據(jù)復(fù)制到堆內(nèi)存里面去而不是在�？臻g里面。 

0x02 漏洞利用

該格式串漏洞很難利用，拷貝到的目的地址不可預(yù)測(cè)并且很難控制。

0x03 結(jié)論 & 引用

該漏洞會(huì)造成遠(yuǎn)程crash，趕緊升級(jí)glibc吧。

感謝阿里安全研究團(tuán)隊(duì)和漏洞分析團(tuán)隊(duì)的努力