轉：https://zhuanlan.zhihu.com/p/27733895?utm_source=tuicool&utm_medium=referral

利用一個堆溢出漏洞實現VMware虛擬機逃逸

[作者：李小龍（acez），中文翻譯：kelwin]

1. 介紹

2017年3月，長亭安全研究實驗室（Chaitin Security Research Lab）參加了Pwn2Own黑客大賽，我作為團隊的一員，一直專註於VMware Workstation Pro的破解，並成功在賽前完成了一個虛擬機逃逸的漏洞利用。（很不）幸運的是，就在Pwn2Own比賽的前一天（3月14日），VMware發布了一個新的版本，其中修復了我們所利用的漏洞。在本文中，我會介紹我們從發現漏洞到完成利用的整個過程。感謝@kelwin在實現漏洞利用過程中給予的幫助，也感謝ZDI的朋友，他們近期也發布了一篇相關博客，正是這篇博文促使我們完成本篇writeup。

本文主要由三部分組成：首先我們會簡要介紹VMware中的RPCI機制，其次我們會描述本文使用的漏洞，最後講解我們是如何利用這一個漏洞來繞過ASLR並實現代碼執行的。

2. VMware RPCI機制

VMware實現了多種虛擬機（下文稱為guest）與宿主機（下文稱文host）之間的通信方式。其中一種方式是通過一個叫做Backdoor的接口，這種方式的設計很有趣，guest只需在用戶態就可以通過該接口發送命令。VMware Tools也部分使用了這種接口來和host通信。我們來看部分相關代碼（摘自open-vm-tools中的lib/backdoor/backdoorGcc64.c）：

void  
Backdoor_InOut(Backdoor_proto *myBp) // IN/OUT  
{
   uint64 dummy;

   __asm__ __volatile__(
#ifdef __APPLE__
        /*
         * Save %rbx on the stack because the Mac OS GCC doesn‘t want us to
         * clobber it - it erroneously thinks %rbx is the PIC register.
         * (Radar bug 7304232)
         */
        "pushq %%rbx"           "\n\t"
#endif
        "pushq %%rax"           "\n\t"
        "movq 40(%%rax), %%rdi" "\n\t"
        "movq 32(%%rax), %%rsi" "\n\t"
        "movq 24(%%rax), %%rdx" "\n\t"
        "movq 16(%%rax), %%rcx" "\n\t"
        "movq  8(%%rax), %%rbx" "\n\t"
        "movq   (%%rax), %%rax" "\n\t"
        "inl %%dx, %%eax"       
 
"\n\t"  /* NB: There is no inq instruction */
        "xchgq %%rax, (%%rsp)"  "\n\t"
        "movq %%rdi, 40(%%rax)" "\n\t"
        "movq %%rsi, 32(%%rax)" "\n\t"
        "movq %%rdx, 24(%%rax)" "\n\t"
        "movq %%rcx, 16(%%rax)" "\n\t"
        "movq %%rbx,  8(%%rax)" "\n\t"
        "popq          (%%rax)" "\n\t"
#ifdef __APPLE__
        "popq %%rbx"            "\n\t"
#endif
      : "=a" (dummy)
      : "0" (myBp)
      /*
       * vmware can modify the whole VM state without the compiler knowing
       * it. So far it does not modify EFLAGS. --hpreg
       */
      :
#ifndef __APPLE__
      /* %rbx is unchanged at the end of the function on Mac OS. */
      "rbx",
#endif
      "rcx", "rdx", "rsi", "rdi", "memory"
   );
}
 

上面的代碼中出現了一個很奇怪的指令inl。在通常環境下（例如Linux下默認的I/O權限設置），用戶態程序是無法執行I/O指令的，因為這條指令只會讓用戶態程序出錯並產生崩潰。而此處這條指令產生的權限錯誤會被host上的hypervisor捕捉，從而實現通信。Backdoor所引入的這種從guest上的用戶態程序直接和host通信的能力，帶來了一個有趣的攻擊面，這個攻擊面正好滿足Pwn2Own的要求：“在這個類型（指虛擬機逃逸這一類挑戰）中，攻擊必須從guest的非管理員帳號發起，並實現在host操作系統中執行任意代碼”。guest將0x564D5868存入$eax，I/O端口號0x5658或0x5659存儲在$dx中，分別對應低帶寬和高帶寬通信。其它寄存器被用於傳遞參數，例如$ecx的低16位被用來存儲命令號。對於RPCI通信，命令號會被設為BDOOR_CMD_MESSAGE（=30）。文件lib/include/backdoor_def.h中包含了一些支持的backdoor命令列表。host捕捉到錯誤後，會讀取命令號並分發至相應的處理函數。此處我省略了很多細節，如果你有興趣可以閱讀相關源碼。

2.1 RPCI

遠程過程調用接口RPCI（Remote Procedure Call Interface）是基於前面提到的Backdoor機制實現的。依賴這個機制，guest能夠向host發送請求來完成某些操作，例如，拖放（Drag n Drop）/復制粘貼（Copy Paste）操作、發送或獲取信息等等。RPCI請求的格式非常簡單：<命令> <參數>。例如RPCI請求info-get guestinfo.ip可以用來獲取guest的IP地址。對於每個RPCI命令，在vmware-vmx進程中都有相關註冊和處理操作。

需要註意的是有些RPCI命令是基於VMCI套接字實現的，但此內容已超出本文討論的範疇。

3. 漏洞

花了一些時間逆向各種不同的RPCI處理函數之後，我決定專註於分析拖放（Drag n Drop，下面簡稱為DnD）和復制粘貼（Copy Paste，下面簡稱為CP）功能。這部分可能是最復雜的RPCI命令，也是最可能找到漏洞的地方。在深入理解的DnD/CP內部工作機理後，可以很容易發現，在沒有用戶交互的情況下，這些處理函數中的許多功能是無法調用的。DnD/CP的核心功能維護了一個狀態機，在無用戶交互（例如拖動鼠標從host到guest中）情況下，許多狀態是無法達到的。

我決定看一看Pwnfest 2016上被利用的漏洞，該漏洞在這個VMware安全公告中有所提及。此時我的idb已經標上了很多符號，所以很容易就通過bindiff找到了補丁的位置。下面的代碼是修補之前存在漏洞的函數（可以看出services/plugins/dndcp/dnddndCPMsgV4.c中有對應源碼，漏洞依然存在於open-vm-tools的git倉庫的master分支當中）：

static Bool  DnDCPMsgV4IsPacketValid(const uint8 *packet,  
                        size_t packetSize)
{
   DnDCPMsgHdrV4 *msgHdr = NULL;
   ASSERT(packet);

   if (packetSize < DND_CP_MSG_HEADERSIZE_V4) {
      return FALSE;
   }

   msgHdr = (DnDCPMsgHdrV4 *)packet;

   /* Payload size is not valid. */
   if (msgHdr->payloadSize > DND_CP_PACKET_MAX_PAYLOAD_SIZE_V4) {
      return FALSE;
   }

   /* Binary size is not valid. */
   if (msgHdr->binarySize > DND_CP_MSG_MAX_BINARY_SIZE_V4) {
      return FALSE;
   }

   /* Payload size is more than binary size. */
   if (msgHdr->payloadOffset + msgHdr->payloadSize > msgHdr->binarySize) { // [1]每個包的binarySize可以手動設置，但是程序默認為不修改。
      return FALSE;
   }

   return TRUE;
}

Bool  
DnDCPMsgV4_UnserializeMultiple(DnDCPMsgV4 *msg,  
                               const uint8 *packet,
                               size_t packetSize)
{
   DnDCPMsgHdrV4 *msgHdr = NULL;
   ASSERT(msg);
   ASSERT(packet);

   if (!DnDCPMsgV4IsPacketValid(packet, packetSize)) {//檢查長度
      return FALSE;
   }

   msgHdr = (DnDCPMsgHdrV4 *)packet;

   /*
    * For each session, there is at most 1 big message. If the received
    * sessionId is different with buffered one, the received packet is for
    * another another new message. Destroy old buffered message.
    */
   if (msg->binary &&
       msg->hdr.sessionId != msgHdr->sessionId) {
      DnDCPMsgV4_Destroy(msg);
   }

   /* Offset should be 0 for new message. */
   if (NULL == msg->binary && msgHdr->payloadOffset != 0) {
      return FALSE;
   }

   /* For existing buffered message, the payload offset should match. */
   if (msg->binary &&
       msg->hdr.sessionId == msgHdr->sessionId &&
       msg->hdr.payloadOffset != msgHdr->payloadOffset) {
      return FALSE;
   }

   if (NULL == msg->binary) {
      memcpy(msg, msgHdr, DND_CP_MSG_HEADERSIZE_V4);
      msg->binary = Util_SafeMalloc(msg->hdr.binarySize);//以第一次設置的長度分配空間
   }

   /* msg->hdr.payloadOffset is used as received binary size. */
   memcpy(msg->binary + msg->hdr.payloadOffset,
          packet + DND_CP_MSG_HEADERSIZE_V4,
          msgHdr->payloadSize); // [2].void *memcpy(void *dest, const void *src, size_t n);
   msg->hdr.payloadOffset += msgHdr->payloadSize;
   return TRUE;
}

對於Version 4的DnD/CP功能，當guest發送分片DnD/CP命令數據包時，host會調用上面的函數來重組guest發送的DnD/CP消息。接收的第一個包必須滿足payloadOffset為0，binarySize代表堆上分配的buffer長度。[1]處的檢查比較了包頭中的binarySize，用來確保payloadOffset和payloadSize不會越界。在[2]處，數據會被拷入分配的buffer中。但是[1]處的檢查存在問題，它只對接收的第一個包有效，對於後續的數據包，這個檢查是無效的，因為代碼預期包頭中的binarySize和分片流中的第一個包相同，但實際上你可以在後續的包中指定更大的binarySize來滿足檢查，並觸發堆溢出。

所以，該漏洞可以通過發送下面的兩個分片來觸發：

packet 1{  
 ...
 binarySize = 0x100
 payloadOffset = 0
 payloadSize = 0x50
 sessionId = 0x41414141
 ...
 #...0x50 bytes...#
}

packet 2{  
 ...
 binarySize = 0x1000
 payloadOffset = 0x50
 payloadSize = 0x100
 sessionId = 0x41414141
 ...
 #...0x100 bytes...#
}

有了以上的知識，我決定看看Version 3中的DnD/CP功能中是不是也存在類似的問題。令人驚訝的是，幾乎相同的漏洞存在於Version 3的代碼中（這個漏洞最初通過逆向分析來發現，但是我們後來意識到v3的代碼也在open-vm-tools的git倉庫中）：

Bool  
DnD_TransportBufAppendPacket(DnDTransportBuffer *buf,          // IN/OUT  
                             DnDTransportPacketHeader *packet, // IN
                             size_t packetSize)                // IN
{
   ASSERT(buf);
   ASSERT(packetSize == (packet->payloadSize + DND_TRANSPORT_PACKET_HEADER_SIZE) &&
          packetSize <= DND_MAX_TRANSPORT_PACKET_SIZE &&
          (packet->payloadSize + packet->offset) <= packet->totalSize &&
          packet->totalSize <= DNDMSG_MAX_ARGSZ);

   if (packetSize != (packet->payloadSize + DND_TRANSPORT_PACKET_HEADER_SIZE) ||
       packetSize > DND_MAX_TRANSPORT_PACKET_SIZE ||
       (packet->payloadSize + packet->offset) > packet->totalSize || //[1]
       packet->totalSize > DNDMSG_MAX_ARGSZ) {
      goto error;
   }

   /*
    * If seqNum does not match, it means either this is the first packet, or there
    * is a timeout in another side. Reset the buffer in all cases.
    */
   if (buf->seqNum != packet->seqNum) {
      DnD_TransportBufReset(buf);
   }

   if (!buf->buffer) {
      ASSERT(!packet->offset);
      if (packet->offset) {
         goto error;
      }
      buf->buffer = Util_SafeMalloc(packet->totalSize);
      buf->totalSize = packet->totalSize;
      buf->seqNum = packet->seqNum;
      buf->offset = 0;
   }

   if (buf->offset != packet->offset) {
      goto error;
   }

   memcpy(buf->buffer + buf->offset,
          packet->payload,
          packet->payloadSize);
   buf->offset += packet->payloadSize;
   return TRUE;

error:  
   DnD_TransportBufReset(buf);
   return FALSE;
}

Version 3的DnD/CP在分片重組時，上面的函數會被調用。此處我們可以在[1]處看到與之前相同的情形，代碼依然假設後續分片中的totalSize會和第一個分片一致。因此這個漏洞可以用和之前相同的方法觸發：

packet 1{  
 ...
 totalSize = 0x100
 payloadOffset = 0
 payloadSize = 0x50
 seqNum = 0x41414141
 ...
 #...0x50 bytes...#
}

packet 2{  
 ...
 totalSize = 0x1000
 payloadOffset = 0x50
 payloadSize = 0x100
 seqNum = 0x41414141
 ...
 #...0x100 bytes...#
}

在Pwn2Own這樣的比賽中，這個漏洞是很弱的，因為它只是受到之前漏洞的啟發，而且甚至可以說是同一個。因此，這樣的漏洞在賽前被修補並不驚訝（好吧，也許我們並不希望這個漏洞在比賽前一天被修復）。對應的VMware安全公告在這裏。受到這個漏洞影響的VMWare Workstation Pro最新版本是12.5.3。

接下來，讓我們看一看這個漏洞是如何被用來完成從guest到host的逃逸的！

4. 漏洞利用

為了實現代碼執行，我們需要在堆上覆蓋一個函數指針，或者破壞C++對象的虛表指針。

首先讓我們看一看如何將DnD/CP協議的設置為version 3，依次發送下列RPCI命令即可：

tools.capability.dnd_version 3  
tools.capability.copypaste_version 3  
vmx.capability.dnd_version  
vmx.capability.copypaste_version  

前兩行消息分別設置了DnD和Copy/Paste的版本，後續兩行用來查詢版本，這是必須的，因為只有查詢版本才會真正觸發版本切換。RPCI命令vmx.capability.dnd_version會檢查DnD/CP協議的版本是否已被修改，如果是，就會創建一個對應版本的C++對象。對於version 3，2個大小為0xA8的C++對象會被創建，一個用於DnD命令，另一個用於Copy/Paste命令。

這個漏洞不僅可以讓我們控制分配的大小和溢出的大小，而且能夠讓我們進行多次越界寫。理想的話，我們可以用它分配大小為0xA8的內存塊，並讓它分配在C++對象之前，然後利用堆溢出改寫C++對象的vtable指針，使其指向可控內存，從而實現代碼執行。

這並非易事，在此之前我們必須解決一些其他問題。首先我們需要找到一個方法來繞過ASLR，同時處理好Windows Low Fragmented Heap。

4.1 繞過ASLR

一般來說，我們需要找到一個對象，通過溢出來影響它，然後實現信息泄露。例如破壞一個帶有長度或者數據指針的對象，並且可以從guest讀取，然而我們沒有找到這種對象。於是我們逆向了更多的RPCI命令處理函數，來尋找可用的東西。那些成對的命令特別引人關註，例如你能用一個命令來設置一些數據，同時又能用相關命令來取回數據，最終我們找到的是一對命令info-set和info-get：

info-set guestinfo.KEY VALUE  
info-get guestinfo.KEY  

VALUE是一個字符串，字符串的長度可以控制堆上buffer的分配長度，而且我們可以分配任意多的字符串。但是如何用這些字符串來泄露數據呢？我們可以通過溢出來覆蓋結尾的null字節，讓字符串連接上相鄰的內存塊。如果我們能夠在發生溢出的內存塊和DnD或CP對象之間分配一個字符串，那麽我們就能泄露對象的vtable地址，從而我們就可以知道vmware-vmx的地址。盡管Windows的LFH堆分配存在隨機化，但我們能夠分配任意多的字符串，因此可以增加實現上述堆布局的可能性，但是我們仍然無法控制溢出buffer後面分配的是DnD還是CP對象。經過我們的測試，通過調整一些參數，例如分配和釋放不同數量的字符串，我們可以實現60%到80%的成功率。

下圖總結了我們構建的堆布局情況（Ov代表溢出內存塊，S代表String，T代表目標對象）。

我們的策略是：首先分配一些填滿“A”的字符串，然後通過溢出寫入一些“B”，接下來讀取所有分配的字符串，其中含有“B”的就是被溢出的字符串。這樣我們就找到了一個字符串可以被用來讀取泄露的數據，然後以bucket的內存塊大小0xA8的粒度繼續溢出，每次溢出後都檢查泄露的數據。由於DnD和CP對象的vtable距離vmware-vmx基地址的偏移是固定的，每次溢出後只需要檢查最低一些數據位，就能夠判斷溢出是否到達了目標對象。

4.2 獲取代碼執行

現在我們實現了信息泄露，也能知道溢出的是哪個C++對象，接下來要實現代碼執行。我們需要處理兩種情形：溢出CopyPaste和DnD。需要指出的是能利用的代碼路徑有很多，我們只是選擇了其中一個。

4.2.1 覆蓋CopyPaste對象

對於CopyPaste對象，我們可以覆蓋虛表指針，讓它指向我們可控的其他數據。我們需要找到一個指針，指針指向的數據是可控並被用做對象的虛表。為此我們使用了另一個RPCI命令unity.window.contents.start。這個命令主要用於Unity模式下，在host上繪制一些圖像。這個操作可以讓我們往相對vmware-vmx偏移已知的位置寫入一些數據。該命令接收的參數是圖像的寬度和高度，二者都是32位，合並起來我們就在已知位置獲得了一個64位的數據。我們用它來作為虛表中的一個指針，通過發送一個CopyPast命令即可觸發該虛函數調用，步驟如下：

• 發送unity.window.contents.start命令，通過指定參數寬度和高度，往全局變量處寫入一個64位的棧遷移gadget地址
• 覆蓋對象虛表指針，指向偽造的虛表（調整虛表地址偏移）
• 發送CopyPaste命令，觸發虛函數調用
• ROP

4.2.2 覆蓋DnD對象

對於DnD對象，我們不能只覆蓋vtable指針，因為在發生溢出之後vtable會立馬被訪問，另一個虛函數會被調用，而目前我們只能通過unity圖像的寬度和高度控制一個qword，所以無法控制更大的虛表。

讓我們看一看DnD和CP對象的結構，總結如下（一些類似的結構可以在open-vm-tools中找到，但是在vmware-vmx中會略有區別）：

DnD_CopyPaste_RpcV3{  
    void * vtable;
    ...
    uint64_t ifacetype;
    RpcUtil{
        void * vtable;
        RpcBase * mRpc;
        DnDTransportBuffer{
            uint64_t seqNum;
            uint8_t * buffer;
            uint64_t totalSize;
            uint64_t offset;
            ...
        }
        ...
    }
}

RpcBase{  
    void * vtable;
    ...
}

我們在此省略了結構中很多與本文無關的屬性。對象中有個指針指向另一個C++對象RpcBase，如果我們能用一個可控數據的指針的指針覆蓋mRpc這個域，那我們就控制了RpcBase的vtable。對此我們可以繼續使用unity.window.contents.start命令來來控制mRpc，該命令的另一個參數是imgsize，這個參數代表分配的圖像buffer的大小。這個buffer分配出來後，它的地址會存在vmware-vmx的固定偏移處。我們可以使用命令unity.window.contents.chunk來填充buffer的內容。步驟如下：

• 發送unity.window.contents.start命令來分配一個buffer，後續我們用它來存儲一個偽造的vtable。
• 發送unity.window.contents.chunk命令來填充偽造的vtable，其中填入一個棧遷移的gadget
• 通過溢出覆蓋DnD對象的mRpc域，讓它指向存儲buffer地址的地方（某全局變量處），即寫入一個指針的指針
• 通過發送DnD命令來觸發mRpc域的虛函數調用
• ROP

P.S：vmware-vmx進程中有一個可讀可寫可執行的內存頁（至少在版本12.5.3中存在）。

4.3 穩定性討論

正如前面提及的，因為Windows LFH堆的隨機化，當前的exploit無法做到100%成功率。不過可以嘗試下列方法來提高成功率：

• 觀察0xA8大小的內存分配，考慮是否可以通過一些malloc和free的調用來實現確定性的LFH分配，參考這裏和這裏。
• 尋找堆上的其他C++對象，尤其是那些可以在堆上噴射的
• 尋找堆上其他帶有函數指針的對象，尤其是那些可以在堆上噴射的
• 找到一個獨立的信息泄漏漏洞
• 打開更多腦洞

4.4 演示效果

演示視頻：

5. 感想與總結

“No pwn no fun”，如果你想參加Pwn2Own這樣的比賽，你就需要準備多個漏洞，或者找到高質量的漏洞。

轉：利用一個堆溢出漏洞實現VMware虛擬機逃逸