作者：[email protected]

0x00 前言

---

之前我們深入瞭解了glibc malloc的執行機制（文章連結請看文末▼），下面就讓我們開始真正的堆溢位漏洞利用學習吧。說實話，寫這類文章，我是比較慫的，因為我當前從事的工作跟漏洞挖掘完全無關，學習這部分知識也純粹是個人愛好，於週末無聊時打發下時間，甚至我最初的目標也僅僅是能快速看懂、復現各種漏洞利用POC而已…鑑於此，後續的文章大致會由兩種內容構成：1)各種相關文章的總結，再提煉；2)某些好文章的翻譯及擴充。本文兩者皆有，主要參考文獻見這裡。

0x01 背景介紹

---

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

#!c
/* 
 Heap overflow vulnerable program. 
 */
#include <stdlib.h>
#include <string.h> 

int main( int argc, char * argv[] )
{
        char * first, * second; 

/*[1]*/ first = malloc( 666 );
/*[2]*/ second = malloc( 12 );
        if(argc!=1)
/*[3]*/         strcpy( first, argv[1] );
/*[4]*/ free( first );
/*[5]*/ free( second );
/*[6]*/ return( 0 );
}

在程式碼3中存在一個堆溢位漏洞：如果使用者輸入的argv1的大小比first變數的666位元組更大的話，那麼輸入的資料就有可能覆蓋掉下一個chunk的chunk header——這可以導致任意程式碼執行。而攻擊的核心思路就是利用glibc malloc的unlink機制。

上述程式的記憶體圖如下所示：

0x02 unlink技術原理

---

2.1 基本知識介紹

unlink攻擊技術就是利用”glibc malloc”的記憶體回收機制，將上圖中的second chunk給unlink掉，並且，在unlink的過程中使用shellcode地址覆蓋掉free函式(或其他函式也行)的GOT表項。這樣當程式後續呼叫free函式的時候(如上面程式碼[5])，就轉而執行我們的shellcode了。顯然，核心就是理解glibc malloc的free機制。

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

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

一旦涉及到free記憶體，那麼就意味著有新的chunk由allocated狀態變成了free狀態，此時glibc malloc就需要進行合併操作——向前以及(或)向後合併。這裡所謂向前向後的概念如下：將previous free chunk合併到當前free chunk，叫做向後合併；將後面的free chunk合併到當前free chunk，叫做向前合併。

一、向後合併：

相關程式碼如下：

#!c
    /*malloc.c  int_free函式中*/
/*這裡p指向當前malloc_chunk結構體，bck和fwd分別為當前chunk的向後和向前一個free chunk*/
/* consolidate backward */
    if (!prev_inuse(p)) {
      prevsize = p->prev_size;
size += prevsize;
//修改指向當前chunk的指標，指向前一個chunk。
      p = chunk_at_offset(p, -((long) prevsize)); 
      unlink(p, bck, fwd);
}   

//相關函式說明：
/* Treat space at ptr + offset as a chunk */
#define chunk_at_offset(p, s)  ((mchunkptr) (((char *) (p)) + (s))) 

/*unlink操作的實質就是：將P所指向的chunk從雙向連結串列中移除，這裡BK與FD用作臨時變數*/
#define unlink(P, BK, FD) {                                            \
    FD = P->fd;                                   \
    BK = P->bk;                                   \
    FD->bk = BK;                                  \
    BK->fd = FD;                                  \
    ...
}

首先檢測前一個chunk是否為free，這可以透過檢測當前free chunk的PREV_INUSE(P)位元位知曉。在本例中，當前chunk（first chunk）的前一個chunk是allocated的，因為在預設情況下，堆記憶體中的第一個chunk總是被設定為allocated的，即使它根本就不存在。

如果為free的話，那麼就進行向後合併：

1)將前一個chunk佔用的記憶體合併到當前chunk;
2)修改指向當前chunk的指標，改為指向前一個chunk。
3)使用unlink宏，將前一個free chunk從雙向迴圈連結串列中移除(這裡最好自己畫圖理解，學過資料結構的應該都沒問題)。

在本例中由於前一個chunk是allocated的，所以並不會進行向後合併操作。

二、向前合併操作：

首先檢測next chunk是否為free。那麼如何檢測呢？很簡單，查詢next chunk之後的chunk的 PREV_INUSE (P)即可。相關程式碼如下：

#!c
……
/*這裡p指向當前chunk*/
nextchunk = chunk_at_offset(p, size);
……
nextsize = chunksize(nextchunk);
……
if (nextchunk != av->top) { 
      /* get and clear inuse bit */
      nextinuse = inuse_bit_at_offset(nextchunk, nextsize);//判斷nextchunk是否為free chunk
      /* consolidate forward */
      if (!nextinuse) { //next chunk為free chunk
            unlink(nextchunk, bck, fwd); //將nextchunk從連結串列中移除
          size += nextsize; // p還是指向當前chunk只是當前chunk的size擴大了，這就是向前合併！
      } else
            clear_inuse_bit_at_offset(nextchunk, 0);    

      ……
    }

整個操作與”向後合併“操作類似，再透過上述程式碼結合註釋應該很容易理解free chunk的向前結合操作。在本例中當前chunk為first，它的下一個chunk為second，再下一個chunk為top chunk，此時 top chunk的 PREV_INUSE位是設定為1的(表示top chunk的前一個chunk，即second chunk, 已經使用)，因此first的下一個chunk不會被“向前合併“掉。

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

#!c
/*
 Place the chunk in unsorted chunk list. Chunks are not placed into regular bins until after they have been given one chance to be used in malloc.
*/  

bck = unsorted_chunks(av); //獲取unsorted bin的第一個chunk
/*
  /* The otherwise unindexable 1-bin is used to hold unsorted chunks. */
    #define unsorted_chunks(M)          (bin_at (M, 1))
*/
      fwd = bck->fd;
      ……
      p->fd = fwd;
      p->bk = bck;
      if (!in_smallbin_range(size))
        {
          p->fd_nextsize = NULL;
          p->bk_nextsize = NULL;
        }
      bck->fd = p;
      fwd->bk = p;  

      set_head(p, size | PREV_INUSE);//設定當前chunk的size,並將前一個chunk標記為已使用
set_foot(p, size);//將後一個chunk的prev_size設定為當前chunk的size
/*
   /* Set size/use field */
   #define set_head(p, s)       ((p)->size = (s))
   /* Set size at footer (only when chunk is not in use) */
   #define set_foot(p, s)       (((mchunkptr) ((char *) (p) + (s)))->prev_size = (s))
*/

上述程式碼完成的整個過程簡要概括如下：將當前chunk插入到unsorted bin的第一個chunk(第一個chunk是連結串列的頭結點，為空)與第二個chunk之間(真正意義上的第一個可用chunk)；然後透過設定自己的size欄位將前一個chunk標記為已使用；再更改後一個chunk的prev_size欄位，將其設定為當前chunk的size。

注意：上一段中描述的”前一個“與”後一個“chunk，是指的由chunk的prev_size與size欄位隱式連線的chunk，即它們在記憶體中是連續、相鄰的！而不是透過chunk中的fd與bk欄位組成的bin(雙向連結串列)中的前一個與後一個chunk，切記！。

在本例中，只是將first chunk新增到unsorted bin中。

2.2 開始攻擊

現在我們再來分析如果一個攻擊者在程式碼3中精心構造輸入資料並透過strcpy覆蓋了second chunk的chunk header後會發生什麼情況。

假設被覆蓋後的chunk header相關資料如下：

1) prev_size = 一個偶數，這樣其PREV_INUSE 位就是0 了，即表示前一個chunk為free。
2) size = -4
3) fd = free 函式的got表地址address – 12；(後文統一簡稱為“free addr – 12”)
4) bk = shellcode的地址

那麼當程式在[4]處呼叫free(first)後會發生什麼呢？我們一步一步分析。

一、向後合併

鑑於first的前一個chunk非free的，所以不會發生向後合併操作。

二、向前合併

先判斷後一個chunk是否為free，前文已經介紹過，glibc malloc透過如下程式碼判斷：

#!c
nextinuse = inuse_bit_at_offset(nextchunk, nextsize);
這裡inuse_bit_at_offset宏定義如下：
/* check/set/clear inuse bits in known places */
#define inuse_bit_at_offset(p, s)                         \
  (((mchunkptr) (((char *) (p)) + (s)))->size & PREV_INUSE)

PS：在本例中next chunk即second chunk，為了便於理解後文統一用next chunk。

從上面程式碼可以知道，它是透過將nextchunk + nextsize計算得到指向下下一個chunk的指標，然後判斷下下個chunk的size的PREV_INUSE標記位。在本例中，此時nextsize被我們設定為了-4，這樣glibc malloc就會將next chunk的prev_size欄位看做是next-next chunk的size欄位，而我們已經將next chunk的prev_size欄位設定為了一個偶數，因此此時透過inuse_bit_at_offset宏獲取到的nextinuse為0，即next chunk為free！既然next chunk為free，那麼就需要進行向前合併，所以就會呼叫unlink(nextchunk, bck, fwd);函式。真正的重點就是這個unlink函式！

在前文2.1節中已經介紹過unlink函式的實現，這裡為了便於說明攻擊思路和過程，再詳細分析一遍，unlink程式碼如下：

#!c
#define unlink(P, BK, FD) {                                            \
    FD = P->fd;                                   \
    BK = P->bk;                                   \
    FD->bk = BK;                                  \
    BK->fd = FD;                                  \
    ...
}

此時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步比較迷惑。我們作圖理解：

結合上圖就很好理解第3，4步了。細心的朋友已經注意到，free addr -12和shellcode addr對應的prev_size等欄位是用虛線標記的，為什麼呢？因為事實上它們對應的記憶體並不是chunk header，只是在我們的攻擊中需要讓glibc malloc在進行unlink操作的時候將它們強制看作malloc_chunk結構體。這樣就很好理解為什麼要用free addr – 12替換next chunk的fd了，因為(free addr -12)->bk剛好就是free addr，也就是說第3步操作的結果就是將free addr處的資料替換為shellcode 的起始地址。

由於已經將free addr處的資料替換為了shellcode的起始地址，所以當程式在程式碼[5]處再次執行free的時候，就會轉而執行shellcode了。

至此，整個unlink攻擊的原理已經介紹完畢，剩下的工作就是根據上述原理，編寫shellcode了。只不過這裡需要注意一點，glibc malloc在unlink的過程中會將shellcode + 8位置的4位元組資料替換為free addr – 12，所以我們編寫的shellcode應該跳過前面的12位元組。

0x03 對抗技術

---

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

3.1 Double Free檢測

該機制不允許釋放一個已經處於free狀態的chunk。因此，當攻擊者將second chunk的size設定為-4的時候，就意味著該size的PREV_INUSE位為0，也就是說second chunk之前的first chunk(我們需要free的chunk)已經處於free狀態，那麼這時候再free(first)的話，就會報出double free錯誤。相關程式碼如下：

#!c
/* Or whether the block is actually not marked used. */
    if (__glibc_unlikely (!prev_inuse(nextchunk)))
      {
            errstr = "double free or corruption (!prev)";
            goto errout;
      }

3.2 next size非法檢測

該機制檢測next size是否在8到當前arena的整個系統記憶體大小之間。因此當檢測到next size為-4的時候，就會報出invalid next size錯誤。相關程式碼如下：

#!c
nextsize = chunksize(nextchunk);
if (__builtin_expect (nextchunk->size <= 2 * SIZE_SZ, 0)
             || __builtin_expect (nextsize >= av->system_mem, 0)){
        errstr = "free(): invalid next size (normal)";
        goto errout;
}

3.3 雙連結串列衝突檢測

該機制會在執行unlink操作的時候檢測連結串列中前一個chunk的fd與後一個chunk的bk是否都指向當前需要unlink的chunk。這樣攻擊者就無法替換second chunk的fd與fd了。相關程式碼如下：

#!c
if (__builtin_expect (FD->bk != P || BK->fd != P, 0))             \
      malloc_printerr (check_action, "corrupted double-linked list", P);      \

0x04 另一種unlink攻擊技術

---

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

0x05 總結

---

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

從上文的分析可以看出，unlink主要還是利用的glibc malloc中隱式連結串列機制，透過覆蓋相鄰chunk的資料實現攻擊，那麼我們能不能在顯示連結串列中也找到攻擊點呢？請關注下一篇文章：基於fastbin的堆溢位漏洞利用介紹。