Pwn2Own2017專題:VMWARE UAF漏洞分析
本文將討論各種VMware主題,包括利用,扭轉和虛擬化VMware目標,從虛擬客戶端到執行代碼。
注意:VMware Workstation 12.5.2及更低版本中都存在此漏洞,不過隨後的VMware Workstation 12.5.3版修補了這些漏洞。此處顯示的所有分析都是在VMware Workstation 12.5.1上完成的。
漏洞分析
在我解釋所涉及的漏洞的細節之前,請先瀏覽一下以下的視頻:
一個比賽的視頻_騰訊視頻 https://v.qq.com/x/page/x0521qt8gu6.html
這個漏洞的好處是它是能夠簡單的觸發。發送以下RPCI請求觸發了此漏洞:
在vmware-vmx.exe上完全啟用了pageheap,WinDbg將會破壞以下異常:
查看bang-heap的輸出給了我更多關於@RCX中的地址的信息。首先,我知道這確實是一種免費使用,其次,我確切知道發生了什麼事情:
下一步是確定該對象的大小。
上面的反彙編表明,釋放的對象大小為0xb8。通過檢查崩潰的指示,我注意到懸掛的指針被保留在一個大小為0x38的對象中,最初是在VM啟動時分配的:
利用漏洞
在崩潰時進行檢查,顯然需要某種信息泄露來利用此漏洞。為了加快這個檢查過程,我使用了一個泄漏vmware-vmx.exe地址的騰訊安全公司的Pwn2Own漏洞。這個特定的信息泄漏將在將來詳細討論,但它確實提供了所需的信息泄漏,使得這個漏洞能夠被成功利用。
通常,當我嘗試利用目標中的漏洞時,我會問自己這些問題:
1.可以發送什麼類型的請求?n2.我該怎麼控制?n3.如何控制崩潰?n4.如何獲得更好的開發原語?n
在本文中,我可以發送RPCI請求,這些請求在技術上可以通過後門介面和其他後門請求一起發送。是的,VMware給這個界面的官方名稱是Backdoor。
那麼,我如何控制被釋放對象的內容呢?我習慣了使用UAF (Use After Free)漏洞,它是一種內存破壞漏洞,通常存在於瀏覽器中在瀏覽器世界,但是利用和控制它對我來說是一件新的挑戰。我開始查看RPC函數,我可以使用普通用戶許可權從Guest訪問,並且我偶然看到了tools.capability.guest_temp_directory。我認為發送一定大小的字元串來覆蓋被釋放的代碼塊很容易。
從技術上講,我們可以通過發送任意RPC請求來控制此漏洞,儘管不一定是tools.capability.guest_temp_directory。
下一個問題是我是否可以將ROP鏈和有效載荷置於確定性的位置。再次,我開始查看可以從Guest訪問的RPC函數。有幾個有趣的功能可供選擇,這其中比較突出的是unity.window.contents.start。仔細看看本次比賽,你就會注意到對內容的引用保存是在一個全局變數中發生的:
換句話說,如果我發送了一個unity.window.contents.start請求,我將確切地知道這個請求的存儲位置:vmware_vmx + 0xb870f8。
所以,我用以下RPC調用再次觸發崩潰:
如上圖所示,@RDI指向觸發該漏洞的請求。
使用將RSP設置為RDI的ROP鏈發送unity.window.contents.start請求。
觸發是的免費,用另一個覆蓋被釋放的對象。釋放的對象應包含vmware_vmx + 0xb870f8的地址。使用包含ROP鏈的請求來觸發重新使用以獲取RCE。
所產生的代碼執行將虛擬客戶端放在虛擬機管理程序層之後。
總結
當在2016年的Pwn2Own中引入VMware時,其實並不希望獲得任何條目。由於研究人員需要查找錯誤和處理所需漏洞的時間,我們很少看到新類別的條目。但是,在2017年的比賽中,就有兩個不同的團隊成功地從虛擬客戶端升級到在虛擬機管理程序中執行代碼。我將來在接下來幾篇文章中詳細說明這些漏洞和技術。
本文翻譯自:Use-After-Silence: Exploiting a quietly patched UAF in VMware ,如若轉載,請註明來源於嘶吼: Pwn2Own2017專題:VMWARE UAF漏洞分析 更多內容請關注「嘶吼專業版」——Pro4hou
推薦閱讀: