一、名詞定義

　　Host機：運行VMware軟件的真實主機;

　　Guest機：裝在VMware軟件中的虛擬系統(tǒng);

　　后門：VMware有一套自己專有的“Backdoor I/O Port”指令，Host和Guest之間的所有數(shù)據(jù)都是通過一個固定的IO端口，使用in和out指令來進行傳遞，Guest就是通過這個端口發(fā)命令讓Host幫助它完成某些自身不能完成的工作。

　　二、漏洞背景

　　理論上來說，可以認(rèn)為Host機和Guest機是兩臺不同的電腦，只不過它們是共享同一套真實的物理硬件，這樣就帶來一個問題，即如何在Host和Guest之間傳輸數(shù)據(jù)， VMware的共享文件夾就是解決該問題的一個很實用功能，不需要設(shè)置任何網(wǎng)絡(luò)，就可以在Host和Guest機器間互相傳輸文件。至于怎么設(shè)置共享文件夾，不是本文的重點，就不多說了，不熟悉的建議Google一下先。

　　在安裝完VMware Tools后，會在Guest機上看到一個名為Hgfs.sys的文件，這個驅(qū)動文件實現(xiàn)了一個虛擬的文件系統(tǒng)，這個虛擬文件系統(tǒng)的根目錄就 是\\.host，當(dāng)你在Guest機上進入任何共享文件夾的目錄時，可以看到路徑都是以\\.host開始的，在這個目錄下的所有操作都將通過后門傳遞 給運行在Host上的VMware主程序。

舉例來說：在Host機上有個目錄是：E:\Debug\Share，把這個目錄設(shè)置為Guest系統(tǒng)的共享目 錄后，VMware會記錄下這個目錄所對應(yīng)的Host路徑是E:\Debug\Share，當(dāng)在Guest機的“運行”對話框中輸入：\\.host \Shared Folders\Share，就會在Guest上打開E:\Debug\Share這個目錄。

這個過程是通過后門完成的，Guest把“遍歷目錄“命令傳 遞給Host，Host上的VMware主程序找到該目錄對應(yīng)關(guān)系，通過API函數(shù)遍歷E:\Debug\Share目錄，把得到的數(shù)據(jù)通過后門返回給 Guest，***Guest上就列出了Share目錄下的所有文件。

　　三、漏洞描述

　　現(xiàn)在就到了本文所要說的重點了。我們知道，當(dāng)Guest位于\\.host\Shared Folders\Share目錄下時，Guest執(zhí)行命令“dir”，就相當(dāng)于要求Host機執(zhí)行“dir E:\Debug\Share”，沒有問題。那再讓Guest執(zhí)行命令“dir ..”，會發(fā)生什么情況呢?

如果是Host本身在執(zhí)行這條命令，沒有問題，自然會列出E:\Debug下的所有文件;但現(xiàn)在要求執(zhí)行命令的是 Guest，Host只設(shè)置了E:\Debug\Share這個目錄給Guest，自然是希望Guest只能看到這個目錄，而沒有權(quán)限看到它的父目錄，因此VMware會對含有“..”的路徑名作特別處理，處理的結(jié)果就是Guest上執(zhí)行這條命令無效。

　　那么它的處理方法是什么呢?簡單說來是這樣的，VMware會對共享文件夾的路徑名進行驗證，確認(rèn)它不含有0×2e0×2e(翻譯為ASCII子字符就是 “..”)字符串后，就會將其從多字節(jié)字符串轉(zhuǎn)換為寬字符字符串，然后將所生成的寬字符字符串傳送給Host上的系統(tǒng)文件API。這個轉(zhuǎn)換使用 Windows API中的MultiByteToWideChar函數(shù)完成。該函數(shù)的原型如下：

　　這里只對dwFlags做簡單解釋。

　　dwFlags：指定是否轉(zhuǎn)換成預(yù)制字符或合成的寬字符，對控制字符是否使用像形文字，以及怎樣處理無效字符。其中：

　　MB_ERR_INVALID_CHARS：設(shè)置此選項，則函數(shù)遇到非法字符就失敗并返回錯誤碼ERROR_NO_UNICODE_TRANSLATION，否則丟棄非法字符。

　　正是由于對MultiByteToWideChar函數(shù)中dwFlags參數(shù)的錯誤使用，導(dǎo)致VMware共享文件夾先后出現(xiàn)了兩個漏洞，按時間順序是 CVE-2007-1744和CVE-2008-0923。

不過嚴(yán)格說起來，這并非是因為VMware開發(fā)人員在使用 MultiByteToWideChar函數(shù)時的編碼錯誤，而是由于這套驗證機制本身在邏輯上就存在一個漏洞。

因為：驗證“..”字符串是在轉(zhuǎn)換輸入字符 串之前執(zhí)行的，因此只要Guest系統(tǒng)上的惡意程序或用戶提供的路徑名可以通過驗證，則在調(diào)用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使用了默認(rèn)值0，這意味著在轉(zhuǎn)換過程中會忽略輸入的無效字符，因此可以很容易地構(gòu)造出一個多字節(jié)字符串，輕松地繞過驗證，成為Unicode UTF-16版本的“..”。示例程序如下：

　　盡管0xc0是無效字符，但因為使用的的dwFlags值是0，所以MultiByteToWideChar函數(shù)會忽略它，而繼續(xù)轉(zhuǎn)換有效的字符 0×2e，所以執(zhí)行這個程序的輸出結(jié)果是：utf16: ..可見，只要我們在輸入的路徑名中包含“0xc00×2e0xc00×2e”，那么就能夠通過VMware對0×2e0×2e的驗證，因此Host會去訪問上層目錄，從而讓Guest看到不應(yīng)該看到的東西。

　　3.2 CVE-2008-0923

　　受影響版本

　　不受影響版本：

　　由于上個漏洞中dwFlags參數(shù)簡單使用了默認(rèn)值0，導(dǎo)致無效字符也能夠順利通過轉(zhuǎn)換，因此VMware的更新版本中將dwFlags參數(shù)的值修 改為 MB_ERR_INVALID_CHARS，這個宏的整數(shù)值是8。這樣一來，像上面使用過的“0xc00×2e0xc00×2e”字符串，由于包含了無效 字符，就會導(dǎo)致MultiByteToWideChar函數(shù)調(diào)用失敗了。那么，我們有沒有辦法構(gòu)造出一個有效的多字節(jié)字符序列，而又能成功轉(zhuǎn)換為 Unicode UTF-16版本的“..”呢?試一試就知道了，還是讓程序來幫忙吧。測試程序如下：

　　很快就能找到第1個字符序列是“0xc20×2e0xc20×2e”，也就是說它能夠通過驗證，并且成功地轉(zhuǎn)換為Unicode UTF-16版本的“..”。