由Ghost漏洞引發(fā)的“血案”

責任編輯:editor005

2015-02-04 14:58:24

摘自:51CTO

*10000000成整形數據“%d %d %d %d”,我們通過分析glibc里面的源代碼stdio-common vfscanf c發(fā)現,將會如下處理 補丁代碼的處理邏輯是把傳入的數據復制到堆內存里面去而不是在??臻g里面。

0x00 背景

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

0x01 分析細節(jié)

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

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

12import socket

socket.gethostbyname('0'*10000000)

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

enter image description here

  通過查看異常信息點發(fā)現,異常發(fā)生在如下代碼處

在memcpy函數進行內存拷貝時出錯

enter image description here

通過分析發(fā)現,rdx是拷貝長度,rsi是源緩沖區(qū),rdi是目的緩沖區(qū),通過分析發(fā)現rsi是我們傳入的數據,而rdi這個地址不能訪問,所以memcpy函數進行拷貝操作時將會出現寫入目的地址空間失敗,通過分析發(fā)現這個地址未初始化,最終導致程序crash.

我們通過分析發(fā)現python語句

12Import socket

Socket.gethostbyname(‘0’*10000000)

將會調用sscanf格式轉換字符串’0’*10000000成整形數據“%d.%d.%d.%d”,我們通過分析glibc里面的源代碼stdio-common/vfscanf.c發(fā)現,將會如下處理

enter image description here

  關鍵問題發(fā)生在宏ADDW,如下代碼是glibc 2.12

這里代碼的作用是把我們傳入的字串循環(huán)拷貝到棧上面去,alloca函數是開辟??臻g,我們知道默認情況下Linux的??臻g是8MB,當我們傳入的參數超長時,會導致??臻g耗盡,導致內存寫上溢,當我們寫入不可預知的未映射的內存時導致程序崩潰. 通過搜索發(fā)現這個格式串漏洞在2.15版被修復

enter image description here

  補丁代碼如下:

enter image description here

補丁代碼的處理邏輯是把傳入的數據復制到堆內存里面去而不是在棧空間里面。 https://sourceware.org/bugzilla/show_bug.cgi?id=13138

0x02 漏洞利用

該格式串漏洞很難利用,拷貝到的目的地址不可預測并且很難控制。

0x03 結論 &引用

該漏洞會造成遠程crash,趕緊升級glibc吧。

感謝阿里安全研究團隊和漏洞分析團隊的努力

引用:

https://sourceware.org/git/?p=glibc.git;a=commit;f=stdio-common/vfscanf.c;h=3f8cc204fdd077da66ffc8e9595158b469e2b8e5

https://sourceware.org/git/?p=glibc.git;a=blob;f=stdio-common/vfscanf.c;h=7356eeb3626665a0524bbf1be37398ea22e05d7e;hb=6164128f1ca84eea240b66f977054e16b94b3c86

http://seclists.org/fulldisclosure/2015/Jan/111

source:http://blog.sina.com.cn/s/blog_e8e60bc00102vhz7.html

鏈接已復制,快去分享吧

企業(yè)網版權所有?2010-2024 京ICP備09108050號-6京公網安備 11010502049343號