VMware漏洞實例分析之共享文件夾目錄遍歷
一、名詞定義
Host機：運行VMware軟件的真實主機;
Guest機：裝在VMware軟件中的虛擬系統;
后門：VMware有一套自己專有的“Backdoor I/O Port”指令，Host和Guest之間的所有數據都是通過一個固定的IO端口，使用in和out指令來進行傳遞，Guest就是通過這個端口發命令讓Host幫助它完成某些自身不能完成的工作。
二、漏洞背景
理論上來說，可以認為Host機和Guest機是兩臺不同的電腦，只不過它們是共享同一套真實的物理硬件，這樣就帶來一個問題，即如何在Host和Guest之間傳輸數據， VMware的共享文件夾就是解決該問題的一個很實用功能，不需要設置任何網絡，就可以在Host和Guest機器間互相傳輸文件。至于怎么設置共享文件夾，不是本文的重點，就不多說了，不熟悉的建議Google一下先。
在安裝完VMware Tools后，會在Guest機上看到一個名為Hgfs.sys的文件，這個驅動文件實現了一個虛擬的文件系統，這個虛擬文件系統的根目錄就 是\\.host，當你在Guest機上進入任何共享文件夾的目錄時，可以看到路徑都是以\\.host開始的，在這個目錄下的所有操作都將通過后門傳遞 給運行在Host上的VMware主程序。
舉例來說：在Host機上有個目錄是：E:\Debug\Share，把這個目錄設置為Guest系統的共享目 錄后，VMware會記錄下這個目錄所對應的Host路徑是E:\Debug\Share，當在Guest機的“運行”對話框中輸入：\\.host \Shared Folders\Share，就會在Guest上打開E:\Debug\Share這個目錄。
這個過程是通過后門完成的，Guest把“遍歷目錄“命令傳 遞給Host，Host上的VMware主程序找到該目錄對應關系，通過API函數遍歷E:\Debug\Share目錄，把得到的數據通過后門返回給 Guest，***Guest上就列出了Share目錄下的所有文件。
三、漏洞描述
現在就到了本文所要說的重點了。我們知道，當Guest位于\\.host\Shared Folders\Share目錄下時，Guest執行命令“dir”，就相當于要求Host機執行“dir E:\Debug\Share”，沒有問題。那再讓Guest執行命令“dir ..”，會發生什么情況呢?
如果是Host本身在執行這條命令，沒有問題，自然會列出E:\Debug下的所有文件;但現在要求執行命令的是 Guest，Host只設置了E:\Debug\Share這個目錄給Guest，自然是希望Guest只能看到這個目錄，而沒有權限看到它的父目錄，因此VMware會對含有“..”的路徑名作特別處理，處理的結果就是Guest上執行這條命令無效。
那么它的處理方法是什么呢?簡單說來是這樣的，VMware會對共享文件夾的路徑名進行驗證，確認它不含有0×2e0×2e(翻譯為ASCII子字符就是 “..”)字符串后，就會將其從多字節字符串轉換為寬字符字符串，然后將所生成的寬字符字符串傳送給Host上的系統文件API。這個轉換使用 Windows API中的MultiByteToWideChar函數完成。該函數的原型如下：
| int MultiByteToWideChar ( UINT CodePage, DWORD dwFlags, LPCSTR lpMultiByteStr, int cbMultiByte, LPWSTR lpWideCharStr, int cchWideChar ); |
這里只對dwFlags做簡單解釋。
dwFlags：指定是否轉換成預制字符或合成的寬字符，對控制字符是否使用像形文字，以及怎樣處理無效字符。其中：
MB_ERR_INVALID_CHARS：設置此選項，則函數遇到非法字符就失敗并返回錯誤碼ERROR_NO_UNICODE_TRANSLATION，否則丟棄非法字符。
正是由于對MultiByteToWideChar函數中dwFlags參數的錯誤使用，導致VMware共享文件夾先后出現了兩個漏洞，按時間順序是 CVE-2007-1744和CVE-2008-0923。
不過嚴格說起來，這并非是因為VMware開發人員在使用 MultiByteToWideChar函數時的編碼錯誤，而是由于這套驗證機制本身在邏輯上就存在一個漏洞。
因為：驗證“..”字符串是在轉換輸入字符 串之前執行的，因此只要Guest系統上的惡意程序或用戶提供的路徑名可以通過驗證，則在調用MultiByteToWideChar之后仍可能映射為包 含有Unicode UTF-16版本的“..”字符串。
3.1 CVE-2007-1744
受影響版本：
VMWare VMWare Workstation 5.5.3 build 34685
不受影響版本：
VMWare VMWare Workstation 5.5.4 build 44386
這個漏洞的起因是dwFlags使用了默認值0，這意味著在轉換過程中會忽略輸入的無效字符，因此可以很容易地構造出一個多字節字符串，輕松地繞過驗證，成為Unicode UTF-16版本的“..”。示例程序如下：
| #include int main(int argc, char* argv[]) { unsigned int ans; char utf8[] = { 0xc0,0×2e,0xc0,0×2e }; //0xc0是無效字符 wchar_t utf16[100] = { 0 }; UINT CodePage = CP_UTF8; ans = MultiByteToWideChar(CodePage, 0, (LPCSTR)&utf8, 4, (LPWSTR)utf16, 100); printf(”utf16: %S\n”, utf16); return 0; } |
盡管0xc0是無效字符，但因為使用的的dwFlags值是0，所以MultiByteToWideChar函數會忽略它，而繼續轉換有效的字符 0×2e，所以執行這個程序的輸出結果是：utf16: ..可見，只要我們在輸入的路徑名中包含“0xc00×2e0xc00×2e”，那么就能夠通過VMware對0×2e0×2e的驗證，因此Host會去訪問上層目錄，從而讓Guest看到不應該看到的東西。
3.2 CVE-2008-0923
受影響版本
| VMWare Workstation 6.0.2 VMWare Workstation 5.5.4 VMWare Player 2.0.2 VMWare Player 1.0.4 VMWare ACE 2.0.2 VMWare ACE 1.0.2 |
不受影響版本：
| VMWare Workstation 6.0.3 VMWare Workstation 5.5.6 VMWare Player 2.0.3 VMWare Player 1.0.5 VMWare ACE 2.0.3 VMWare ACE 1.0.5 VMWare ESX VMWare Server |
由于上個漏洞中dwFlags參數簡單使用了默認值0，導致無效字符也能夠順利通過轉換，因此VMware的更新版本中將dwFlags參數的值修 改為 MB_ERR_INVALID_CHARS，這個宏的整數值是8。這樣一來，像上面使用過的“0xc00×2e0xc00×2e”字符串，由于包含了無效 字符，就會導致MultiByteToWideChar函數調用失敗了。那么，我們有沒有辦法構造出一個有效的多字節字符序列，而又能成功轉換為 Unicode UTF-16版本的“..”呢?試一試就知道了，還是讓程序來幫忙吧。測試程序如下：
| #include #include #include int main(int argc, char* argv[]) { unsigned int i, ans; unsigned char buf[200]; UINT CodePage = CP_UTF8; for (i=1; i; i++) { memset(buf, 0, 200); ans = MultiByteToWideChar(CodePage, MB_ERR_INVALID_CHARS, //8 (LPCSTR)&i, 4, (LPWSTR)buf, 100); if (ans && (buf[0] == ‘.’) && (buf[1] == 0) && ((i & 0xff) != ‘.’)) { printf(”%d %04x: %02x %02x %02x %02x\n”, ans, i, buf[0], buf[1], buf[2], buf[3]); getchar(); // 找到后讓程序暫停一下 } } return 0; } |
很快就能找到第1個字符序列是“0xc20×2e0xc20×2e”，也就是說它能夠通過驗證，并且成功地轉換為Unicode UTF-16版本的“..”。
