新爆內(nèi)核高危漏洞sock_sendpage的利用分析的討論

CUDev

PER_SVR4以及MAP_ZERO了，不用再mmap了，只需要mprotect修改一下權(quán)限即可。

emmoblin

我還是有些不明白：
這個代碼最關(guān)鍵的是
mmap(0x0, 0x1000, PROT_READ | PROT_WRITE, MAP_FIXED | MAP_ANONYMOUS, 0, 0)

MAP_FIXED的作用就是強(qiáng)行映射到指定的addr的位置。
MAP_ANONYMOUS將忽略 fd和offset參數(shù)。

疑問一：
既然沒有傳入fd，那么到底把哪個文件或者內(nèi)存映射到了地址0呢？
難道是內(nèi)核空間的內(nèi)存？

疑問二：
return sock->ops->sendpage(sock, page, offset, size, flags);
在內(nèi)核空間執(zhí)行時應(yīng)該看到的是進(jìn)程的全部4G空間。
這個跳轉(zhuǎn)到0地址執(zhí)行，這個0地址指的是進(jìn)程的虛擬地址0嗎？

如果是進(jìn)程空間的虛擬地址0，那么為什么不直接在進(jìn)程的虛擬地址0直接寫入jmp指令呢？
到底為什么要作mmap呢？

疑問三：
sock->ops->sendpage
到底在什么情況下是NULL呢？難道內(nèi)核的sendpage就不能用嗎？
還是只有
socket(PF_PPPOX, SOCK_DGRAM, 0)才會導(dǎo)致sendpage指針為NULL呢？

[ 本帖最后由 emmoblin 于 2009-8-21 00:00 編輯 ]

kouu

1、這里的mmap應(yīng)該就相當(dāng)于malloc時，libc做的mmap一樣（malloc大塊內(nèi)存的時候），就是把0地址的空間分配給用戶；
2、不做mmap的話，虛擬地址空間的0地址是沒有分配的，沒有對應(yīng)的vma，缺頁異常會導(dǎo)致程序被殺死；
3、sock->ops->sendpage是NULL也是內(nèi)核BUG之一。不少類型的socket都沒有sendfile這個函數(shù)，但是它們大多數(shù)都會使用sock_no_sendpage來代替一下，并不會留空。但是PF_PPPOX卻留的是NULL，我發(fā)現(xiàn)PF_BLUETOOTH也是一樣的效果，而PF_INET之類的卻不行；

emmoblin

謝謝kouu，明白多了。

也就是使用mmap在0地址分配一段空間，然后就可以在此空間寫入代碼了。

但是這樣都行，難道m(xù)map可以隨便指定一個地址嗎？
比如我指定0x50000000，正好這個地址是有用的，那豈不是破壞了這段內(nèi)存？
程序還不跑亂了？

[ 本帖最后由 emmoblin 于 2009-8-21 00:49 編輯 ]

kouu

按我的理解，mmap就是在mm上加一個vma。如果這個vma與現(xiàn)有的vma有重疊，如果其屬性一樣的話，mmap應(yīng)該是可以成功的，并且新老兩個vma被合并成一個。否則mmap會失敗。
另外，mmap的地址參數(shù)多數(shù)情況下只是個參考，內(nèi)核不一定map到給定的地址上，實(shí)際map的地址會通過返回值給出。但是本例中mmap使用了MAP_FIXED參數(shù)，應(yīng)該就是不允許內(nèi)核map到其他地址了，map不成功則直接返回失敗。

zengdesheng

感謝分享。

emmoblin

那我覺得內(nèi)核mmap的時候應(yīng)該避免映射到0地址。及時用了FIXED參數(shù)。
這樣就利用不了NULL跳轉(zhuǎn)到0地址執(zhí)行的漏洞了

kouu

原帖由 emmoblin 于 2009-8-23 10:37 發(fā)表
那我覺得內(nèi)核mmap的時候應(yīng)該避免映射到0地址。及時用了FIXED參數(shù)。
這樣就利用不了NULL跳轉(zhuǎn)到0地址執(zhí)行的漏洞了

原帖由 kouu 于 2009-8-19 14:58 發(fā)表
不過我感覺內(nèi)核應(yīng)該限制一下對0地址的分配（任何vma都不能包含0地址），因?yàn)榱?xí)慣上很多情況下都把NULL看成是非法的了。

:wink: 同感, 呵呵

CUDev

http://www.milw0rm.com/exploits/9479

milw0rm上的一個exploit中有一段解釋，來支持這個觀點(diǎn)：

        /*
        ** By calling iret after pushing a register into kernel stack,
        ** We don't have to go back to ring3(user mode) privilege level. dont worry. :-}
        **
        ** kernel_code() function will return to its previous status which means before sendfile() system call,
        ** after operating upon a ring0(kernel mode) privilege level.
        ** This will enhance the viablity of the attack code even though each kernel can have different CS and DS address.
        */

kouu

按我的理解，在kernel_code中return，并不是直接返回到用戶態(tài)去的。
sendfile系統(tǒng)調(diào)用有自己的流程：創(chuàng)建一個pipe作緩沖用、從in_fd讀數(shù)據(jù)到pipe、將pipe的數(shù)據(jù)寫到out_fd、循環(huán)直到滿足條件……
存在漏洞的sock_sendpage函數(shù)是在“將pipe的數(shù)據(jù)寫到out_fd”這個階段，從kernel_code返回也就是退出這個階段。

這里有兩個問題：
1、kernel_code返回值是void，但是原本的sock->ops->sendpage是有ssize_t返回值的，于是kernel_code返回后，上層調(diào)用者將在棧中得到一個假的返回值；
2、kernel_code返回后，循環(huán)會退出嗎（sendfile完畢 或 出錯）？（可以看到，#49的鏈接中，用戶態(tài)調(diào)用sendfile時的count參數(shù)值為2，但LZ的例子中這個值是PAGE_SIZE，可能是為了退出循環(huán)）；

如果以上兩個問題處理不當(dāng)，直接從kernel_code返回可能是有問題的。如果沒有問題，那么可能是巧合、或者是作者精心考慮過的。


另外，#49 鏈接給出的代碼中，通過一個棧變量where的地址來找到tast_struct，感覺確實(shí)比用匯編來取ESP好~