Linux堆溢出漏洞利用之unlink

作者：走位@阿里聚安全

0 前言

之前我們深入了解了glibc malloc的運行機制（文章鏈接請看文末▼），下面就讓我們開始真正的堆溢出漏洞利用學(xué)習(xí)吧。說實話，寫這類文章，我是比較慫的，因為我當(dāng)前從事的工作跟漏洞挖掘完全無關(guān)，學(xué)習(xí)這部分知識也純粹是個人愛好，于周末無聊時打發(fā)下時間，甚至我最初的目標(biāo)也僅僅是能快速看懂、復(fù)現(xiàn)各種漏洞利用POC而已…鑒于此，后續(xù)的文章大致會由兩種內(nèi)容構(gòu)成：1)各種相關(guān)文章的總結(jié)，再提煉；2)某些好文章的翻譯及拓展。本文兩者皆有，主要參考文獻見這里。

1 背景介紹

首先，存在漏洞的程序如下：

在代碼[3]中存在一個堆溢出漏洞：如果用戶輸入的argv[1]的大小比first變量的666字節(jié)更大的話，那么輸入的數(shù)據(jù)就有可能覆蓋掉下一個chunk的chunk header——這可以導(dǎo)致任意代碼執(zhí)行。而攻擊的核心思路就是利用glibc malloc的unlink機制。

上述程序的內(nèi)存圖如下所示：

2 unlink技術(shù)原理

2.1 基本知識介紹

unlink攻擊技術(shù)就是利用”glibc malloc”的內(nèi)存回收機制，將上圖中的second chunk給unlink掉，并且，在unlink的過程中使用shellcode地址覆蓋掉free函數(shù)(或其他函數(shù)也行)的GOT表項。這樣當(dāng)程序后續(xù)調(diào)用free函數(shù)的時候(如上面代碼[5])，就轉(zhuǎn)而執(zhí)行我們的shellcode了。顯然，核心就是理解glibc malloc的free機制。

在正常情況下，free的執(zhí)行流程如下文所述：

PS: 鑒于篇幅，這里主要介紹非mmaped的chunks的回收機制，回想一下在哪些情況下使用mmap分配新的chunk，哪些情況下不用mmap？

一旦涉及到free內(nèi)存，那么就意味著有新的chunk由allocated狀態(tài)變成了free狀態(tài)，此時glibc malloc就需要進行合并操作——向前以及(或)向后合并。這里所謂向前向后的概念如下：將previous free chunk合并到當(dāng)前free chunk，叫做向后合并；將后面的free chunk合并到當(dāng)前free chunk，叫做向前合并。

一、向后合并：

相關(guān)代碼如下：

首先檢測前一個chunk是否為free，這可以通過檢測當(dāng)前free chunk的PREV_INUSE(P)比特位知曉。在本例中，當(dāng)前chunk（first chunk）的前一個chunk是allocated的，因為在默認情況下，堆內(nèi)存中的第一個chunk總是被設(shè)置為allocated的，即使它根本就不存在。

如果為free的話，那么就進行向后合并：

1)將前一個chunk占用的內(nèi)存合并到當(dāng)前chunk;

2)修改指向當(dāng)前chunk的指針，改為指向前一個chunk。

3)使用unlink宏，將前一個free chunk從雙向循環(huán)鏈表中移除(這里最好自己畫圖理解，學(xué)過數(shù)據(jù)結(jié)構(gòu)的應(yīng)該都沒問題)。

在本例中由于前一個chunk是allocated的，所以并不會進行向后合并操作。

二、向前合并操作：

首先檢測next chunk是否為free。那么如何檢測呢？很簡單，查詢next chunk之后的chunk的PREV_INUSE (P)即可。相關(guān)代碼如下：

整個操作與”向后合并“操作類似，再通過上述代碼結(jié)合注釋應(yīng)該很容易理解free chunk的向前結(jié)合操作。在本例中當(dāng)前chunk為first，它的下一個chunk為second，再下一個chunk為top chunk，此時top chunk的PREV_INUSE位是設(shè)置為1的(表示top chunk的前一個chunk，即second chunk,已經(jīng)使用)，因此first的下一個chunk不會被“向前合并“掉。

介紹完向前、向后合并操作，下面就需要了解合并后(或因為不滿足合并條件而沒合并)的chunk該如何進一步處理了。在glibc malloc中，會將合并后的chunk放到unsorted bin中(還記得unsorted bin的含義么？)。相關(guān)代碼如下：

上述代碼完成的整個過程簡要概括如下：將當(dāng)前chunk插入到unsorted bin的第一個chunk(第一個chunk是鏈表的頭結(jié)點，為空)與第二個chunk之間(真正意義上的第一個可用chunk)；然后通過設(shè)置自己的size字段將前一個chunk標(biāo)記為已使用；再更改后一個chunk的prev_size字段，將其設(shè)置為當(dāng)前chunk的size。

注意：上一段中描述的”前一個“與”后一個“chunk，是指的由chunk的prev_size與size字段隱式連接的chunk，即它們在內(nèi)存中是連續(xù)、相鄰的！而不是通過chunk中的fd與bk字段組成的bin(雙向鏈表)中的前一個與后一個chunk，切記！。

在本例中，只是將first chunk添加到unsorted bin中。

2.2 開始攻擊

現(xiàn)在我們再來分析如果一個攻擊者在代碼[3]中精心構(gòu)造輸入數(shù)據(jù)并通過strcpy覆蓋了second chunk的chunk header后會發(fā)生什么情況。

假設(shè)被覆蓋后的chunk header相關(guān)數(shù)據(jù)如下：

1) prev_size =一個偶數(shù)，這樣其PREV_INUSE位就是0了，即表示前一個chunk為free。

2) size = -4

3) fd = free函數(shù)的got表地址address – 12；(后文統(tǒng)一簡稱為“free addr – 12”)

4) bk = shellcode的地址

那么當(dāng)程序在[4]處調(diào)用free(first)后會發(fā)生什么呢？我們一步一步分析。

一、向后合并

鑒于first的前一個chunk非free的，所以不會發(fā)生向后合并操作。

二、向前合并

先判斷后一個chunk是否為free，前文已經(jīng)介紹過，glibc malloc通過如下代碼判斷：

PS：在本例中next chunk即second chunk，為了便于理解后文統(tǒng)一用next chunk。

從上面代碼可以知道，它是通過將nextchunk + nextsize計算得到指向下下一個chunk的指針，然后判斷下下個chunk的size的PREV_INUSE標(biāo)記位。在本例中，此時nextsize被我們設(shè)置為了-4，這樣glibc malloc就會將next chunk的prev_size字段看做是next-next chunk的size字段，而我們已經(jīng)將next chunk的prev_size字段設(shè)置為了一個偶數(shù)，因此此時通過inuse_bit_at_offset宏獲取到的nextinuse為0，即next chunk為free！既然next chunk為free，那么就需要進行向前合并，所以就會調(diào)用unlink(nextchunk, bck, fwd);函數(shù)。真正的重點就是這個unlink函數(shù)！

在前文2.1節(jié)中已經(jīng)介紹過unlink函數(shù)的實現(xiàn)，這里為了便于說明攻擊思路和過程，再詳細分析一遍，unlink代碼如下：

此時P = nextchunk, BK = bck, FD = fwd。

1)首先FD = nextchunk->fd = free地址– 12;

2)然后BK = nextchunk->bk = shellcode起始地址；

3)再將BK賦值給FD->bk，即（free地址– 12）->bk = shellcode起始地址；

4)最后將FD賦值給BK->fd，即(shellcode起始地址)->fd = free地址– 12。

前面兩步還好理解，主要是后面2步比較迷惑。我們作圖理解：

結(jié)合上圖就很好理解第3，4步了。細心的朋友已經(jīng)注意到，free addr -12和shellcode addr對應(yīng)的prev_size等字段是用虛線標(biāo)記的，為什么呢？因為事實上它們對應(yīng)的內(nèi)存并不是chunk header，只是在我們的攻擊中需要讓glibc malloc在進行unlink操作的時候?qū)⑺鼈儚娭瓶醋鱩alloc_chunk結(jié)構(gòu)體。這樣就很好理解為什么要用free addr – 12替換next chunk的fd了，因為(free addr -12)->bk剛好就是free addr，也就是說第3步操作的結(jié)果就是將free addr處的數(shù)據(jù)替換為shellcode的起始地址。

由于已經(jīng)將free addr處的數(shù)據(jù)替換為了shellcode的起始地址，所以當(dāng)程序在代碼[5]處再次執(zhí)行free的時候，就會轉(zhuǎn)而執(zhí)行shellcode了。

至此，整個unlink攻擊的原理已經(jīng)介紹完畢，剩下的工作就是根據(jù)上述原理，編寫shellcode了。只不過這里需要注意一點，glibc malloc在unlink的過程中會將shellcode + 8位置的4字節(jié)數(shù)據(jù)替換為free addr – 12，所以我們編寫的shellcode應(yīng)該跳過前面的12字節(jié)。

3 對抗技術(shù)

當(dāng)前，上述unlink技術(shù)已經(jīng)過時了(但不代表所有的unlink技術(shù)都失效，詳情見后文)，因為glibc malloc對相應(yīng)的安全機制進行了加強，具體而言，就是添加了如下幾條安全檢測機制。

3.1 Double Free檢測

該機制不允許釋放一個已經(jīng)處于free狀態(tài)的chunk。因此，當(dāng)攻擊者將second chunk的size設(shè)置為-4的時候，就意味著該size的PREV_INUSE位為0，也就是說second chunk之前的first chunk(我們需要free的chunk)已經(jīng)處于free狀態(tài)，那么這時候再free(first)的話，就會報出double free錯誤。相關(guān)代碼如下：

3.2 next size非法檢測

該機制檢測next size是否在8到當(dāng)前arena的整個系統(tǒng)內(nèi)存大小之間。因此當(dāng)檢測到next size為-4的時候，就會報出invalid next size錯誤。相關(guān)代碼如下：

3.3 雙鏈表沖突檢測

該機制會在執(zhí)行unlink操作的時候檢測鏈表中前一個chunk的fd與后一個chunk的bk是否都指向當(dāng)前需要unlink的chunk。這樣攻擊者就無法替換second chunk的fd與fd了。相關(guān)代碼如下：

4 另一種unlink攻擊技術(shù)

經(jīng)過上述3層安全檢測，是否意味著所有unlink技術(shù)都失效了呢？答案是否定的，因為進行漏洞攻擊的人腦洞永遠比天大！之前剛好看到一篇好文(強烈推薦)，主講在Android4.4上利用unlink機制實現(xiàn)堆溢出攻擊。眾所周知，Android內(nèi)核基于linux，且其堆內(nèi)存管理也是使用的glibc malloc，雖然在一些細節(jié)上有些許不同，但核心原理類似。該文介紹的攻擊方式就成功繞過了上述三層檢測。

5 總結(jié)

本文詳細介紹了unlink攻擊技術(shù)的核心原理，雖然上述介紹的unlink漏洞利用技術(shù)已經(jīng)失效，而其他的unlink技術(shù)難度也越來越大，但是我們還是有必要認真學(xué)習(xí)，因為它一方面可以進一步加深我們對glibc malloc的堆棧管理機制的理解，另一方面也為后續(xù)的各種堆溢出攻擊技術(shù)提供了思路。

從上文的分析可以看出，unlink主要還是利用的glibc malloc中隱式鏈表機制，通過覆蓋相鄰chunk的數(shù)據(jù)實現(xiàn)攻擊，那么我們能不能在顯示鏈表中也找到攻擊點呢？請關(guān)注下一篇文章：基于fastbin的堆溢出漏洞利用介紹。

Linux技術(shù)分析系列文章

Linux堆內(nèi)存管理深入分析(上)

Linux堆內(nèi)存管理深入分析（下）

作者：走位@阿里聚安全，更多安全技術(shù)文章，請訪問阿里聚安全博客

總結(jié)

以上是生活随笔為你收集整理的Linux堆溢出漏洞利用之unlink的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。