動(dòng)態(tài)鏈接庫的靜態(tài)鏈接導致程序的DLL劫持漏洞
借助QQ程序xGraphic32.dll描述
一、 庫
首先明確一下庫的概念，庫里存放的都是二進(jìn)制編碼?？v觀(guān)編程技術(shù)的發(fā)展路線(xiàn)，可以看到一條清晰的發(fā)展脈絡(luò )：代碼>靜態(tài)庫>動(dòng)態(tài)庫。
假如我們要編寫(xiě)一個(gè)程序叫做Calc.exe，而現在有現成的庫，庫里面存放的是已經(jīng)編譯好的函數Add()，Sub()以及其他相關(guān)的符號等等，并且靜態(tài)庫(calcfun.lib)和動(dòng)態(tài)庫(calcfun.dll)各有一個(gè)版本。
那么我們就只需要編碼Calc.exe的主程序，在其中使用庫中的函數(可以導出函數類(lèi)常量等待這些統稱(chēng)為符號)，而不需要在編碼實(shí)現這些函數。
A. 使用靜態(tài)庫
靜態(tài)庫只有一個(gè)lib文件calcfun.lib(忽略導出函數聲明calcfun.h文件)，這個(gè)lib文件里面包含的就是二進(jìn)制編碼。在鏈接期間，鏈接器將會(huì )抽出庫中我們所引用的符號的二進(jìn)制編碼，并且把這些二進(jìn)制編碼合并到生成的Calc.exe中，最終我們得到的程序就只有并且只需要一個(gè)Calc.exe就可以運行(這里忽略了操作系統系統所需的庫)。
B. 使用動(dòng)態(tài)庫
標準的動(dòng)態(tài)庫一般有兩個(gè)文件calcfun.dll，calcfun.lib(忽略導出函數聲明calcfun.h文件)，不要混淆這個(gè)lib文件與上述的靜態(tài)庫lib文件，這個(gè)lib文件準確的名稱(chēng)是到導入庫，包含的是dll中導出符號的地址表，只是提供給鏈接器定位dll中符號之用，并不是二進(jìn)制代碼，真正的二進(jìn)制代碼存在于calcfun.dll中。為什么會(huì )有兩個(gè)文件？因為對于動(dòng)態(tài)鏈接庫的使用方法可以有兩種：靜態(tài)鏈接(隱式鏈接)，動(dòng)態(tài)鏈接(顯示鏈接)。
1) 靜態(tài)鏈接(隱式鏈接)
也只有使用這種方式的時(shí)候才會(huì )用到動(dòng)態(tài)庫的lib文件，即導入庫calcfun.lib，這種方式的效果是在生成的calc.exe的PE頭部的導入表中添加了一IMAGE_IMPORT_DESCRIPTOR，并且根據程序中所引用的符號寫(xiě)入了相應的IMAGE_THUNK_DATA，最終生成的calc.exe若要能正確運行必須依賴(lài)于calcfun.dll。這種鏈接方式的實(shí)現是設置鏈接器參數，比如vc的鏈接器可以直接把倒入庫當作參數傳遞給鏈接器link.exe，也可以使用預編譯處理：#pragma comment(lib, "calcfun.lib")
2) 動(dòng)態(tài)鏈接(顯示鏈接)
使用這種鏈接方式只需要一個(gè)dll文件，lib文件就是多余的了，因為dll本身也包含自身導出符號的地址表，所以只需要把這個(gè)dll載入到我們的程序的地址空間，然后搜索到我們需要使用的函數或者其他符號的地址就可以了。這種鏈接方式不會(huì )添加信息到生成的calc.exe的PE頭部。生成的calc.exe若要能正確云清必須依賴(lài)于calcfun.dll。這種鏈接方式的實(shí)現是通過(guò)LoadLibrary()載入dll模塊，通過(guò)GetProcessAddress()來(lái)搜索到目標符號的地址，通過(guò)FreeLibrary()卸載dll模塊。
3) 載入時(shí)機
動(dòng)態(tài)庫除了上述使用方式不同之外，還有就是真正載入的時(shí)機。編譯是我們來(lái)做的，而運行時(shí)的各種工作都是由操作系統來(lái)做的。靜態(tài)鏈接生成的exe中的PE頭部的導入表里包含了所需的dll信息，所以程序Loader會(huì )讀取導入表，并加載導入表中的所有的dll(延遲加載除外，本文不討論)。而動(dòng)態(tài)鏈接庫則是在程序調用LoadLibrary()函數時(shí)才會(huì )載入指定的dll。
靜態(tài)庫沒(méi)有動(dòng)態(tài)庫常見(jiàn)，所以現在普遍存在于windwos操作系統中的都是動(dòng)態(tài)鏈接庫，從上面的介紹可知道，DLL最終被載入程序的進(jìn)程空間都是操作系統來(lái)完成，那么操作系統如何知道所需的DLL的位置呢？很明顯，操作系統需要一套搜索規則來(lái)加載動(dòng)態(tài)鏈接庫。
二、 動(dòng)態(tài)鏈接庫(DLL)的搜索順序
程序可以通過(guò)指定全路徑或者使用清單等機制來(lái)控制從何處加載DLL，如果沒(méi)有使用這些方法，系統將會(huì )進(jìn)行DLL搜索。
A. 影響搜索的要素
1. 如果一個(gè)同名的DLL已經(jīng)被加載入內存中，系統在解析即將被載入的DLL前只會(huì )檢查重定向和清單，無(wú)論這個(gè)DLL在哪一個(gè)目錄，也就是說(shuō)系統不會(huì )去搜索DLL。
2. 如果一個(gè)程序所需的DLL在本機的Known DLLs列表中存在，系統將直接使用這個(gè)已知的DLL而不會(huì )去搜索DLL。當前系統的Know DLLs列表在注冊表中的路徑：HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SessionManager\KnownDLLs
3. 如果一個(gè)DLL(例如a.dll)依賴(lài)于其他的DLL(例如b.dll,c.dll等等)，系統將會(huì )只按照模塊名來(lái)搜索依賴(lài)的DLL(b.dll,c.dll...)，即使第一個(gè)DLL(a.dll)是通過(guò)全路徑加載的，這條規則也適用。
B. 標準的搜索順序
系統有一套標準的搜索DLL路徑的規則，這套規則又分為兩種搜索模式，安全搜索模式，非安全搜索模式。安全搜索模式是默認開(kāi)啟的，如果要禁用安全搜索模式，可以在注冊表中創(chuàng )建HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SessionManager\SafeDllSearchMode鍵值，并且設置值為0。
1. 安全搜索模式順序
>1.exe程序的所在目錄
>2.系統目錄(GetSystemDirectory()獲得)
>3.16位系統目錄
>4.Windows目錄
>5.進(jìn)程當前目錄
>6.系統PATH環(huán)境變量中的目錄
2. 非安全搜索模式
>1.exe程序的所在目錄
>2.進(jìn)程當前目錄
>3.系統目錄(GetSystemDirectory()獲得)
>4.16位系統目錄
>5.Windows目錄.
>6.系統PATH環(huán)境變量中的目錄
所有通過(guò)靜態(tài)鏈接的動(dòng)態(tài)鏈接庫都遵循以上A.B搜索順序的規則。
C. 通過(guò)LoadLibrary(LPCTSTR lpFileName)或者LoadLibraryEx(LPCTSTRlpFileName, …)函數實(shí)現的動(dòng)態(tài)鏈接，則有一下規則。
1. lpFileName包含文件路徑+文件名
則先搜索指定路徑的文件，文件存在則函數返回成功，文件不存在函數返回失敗。
2. lpFileName不包含文件路徑+文件名
函數將轉而使用系統的標準搜索路徑
關(guān)于動(dòng)態(tài)鏈接庫的搜索順序的更多詳細資料請參閱http://msdn.microsoft.com/en-us/library/ms682586%28VS.85%29.aspx
三、 QQ程序存在的一個(gè)DLL劫持利用漏洞
這個(gè)漏洞應該是QQ2009版本之后到目前為止一直存在的漏洞。漏洞的形成原因是QQ的界面引擎GF.dll引入的。
先來(lái)說(shuō)一下MSIMG32.DLL這個(gè)文件，這個(gè)文件是windows GDI函數簇的一個(gè)庫其中只有四個(gè)函數
存在于系統目錄C:\windows\system32\msimg32.dll。
我們用Dependency Walker查看一下QQ.exe啟動(dòng)的時(shí)候，存在的DLL依賴(lài)關(guān)系：
QQ.exe ->GF.dll -> xGraphic32.dll -> Msimg32.dl。
在這里可能有人會(huì )說(shuō)，從那個(gè)帶箭頭的圖標來(lái)看Msimg32顯示是已經(jīng)被加載過(guò)了。有這個(gè)疑問(wèn)是正常的，我們可以看到另一條依賴(lài)關(guān)系鏈：QQ.exe -> User32.dll->Msimg32.dl。
乍一看沒(méi)有問(wèn)題，不存在劫持的可能：有這樣一個(gè)規則，Windows在加載時(shí)讀取exe的導入表，然后加載依賴(lài)模塊，但是無(wú)論導入表的順序如何，只要導入表中存在的dll并且在Knows Dll列表中存在，那么系統就會(huì )優(yōu)先加載這些模塊，User32.dll是肯定存在與Knows Dll列表中的，那么User32.dll肯定先于GF.dll的加載，這樣一來(lái)，系統就會(huì )直接加載系統目錄下的User32.dll，User32.dll又會(huì )從自己所在目錄加載Msimg32.dll(即系統的原始msimg32.dll)，那么后面再加載GF->xGraphic32.dll->Msimg32.dll就會(huì )直接返回之前加載過(guò)的木塊句柄，這樣看就不存在Msimg32.dll被劫持的可能了。
不過(guò)，讀者應該看到User32.dll中的msimg32.dll前面的圖標顯示是延遲加載的！所以只要QQ.exe在加載xGraphic32.dll之前不調用msimg32.dll中導出的任何函數，這個(gè)模塊就不會(huì )被加載，所以最終第一次加載msimg32.dll應該是在xGraphic32.dll中。那么QQ程序中到底是如何呢？我們可以用Process Monitor來(lái)驗證一下！
設置Process Monitor的過(guò)濾選項。然后啟動(dòng)QQ.EXE
在QQ啟動(dòng)完成顯示出登錄窗口后產(chǎn)看“文件操作”捕獲結果，搜索msimg32
發(fā)現，第一次加載確實(shí)實(shí)在xGraphic32.dll中！
真相：QQ.EXE中第一次加載msimg32.dll是在一個(gè)非系統模塊中，并且msimg32.dll沒(méi)有被微軟列為KnownDlls。所以如果第三方軟件開(kāi)發(fā)者實(shí)現了一個(gè)模塊，并且在自己的模塊中靜態(tài)鏈接了msimg32.dll的話(huà)，那么就留下了一個(gè)可以利用系統搜索DLL順序來(lái)進(jìn)行DLL劫持的漏洞。很不幸，GF的依賴(lài)模塊xGraphic32.dll就是這樣一個(gè)模塊。
結合上述標準搜索順序，當加載xGraphic32.dll模塊的時(shí)候依賴(lài)msimg32.dll，然后系統先搜索QQ.exe所在目錄，如果不存在則搜索則繼續按照規則搜索，最終能搜索到系統目錄下的原始的msimg32.dll。但是，如果有人通過(guò)DLL導出符號轉發(fā)器實(shí)現了一個(gè)偽造的msimg32.dll放置于QQ.exe的目錄中會(huì )有什么后果呢？無(wú)論有沒(méi)有開(kāi)啟安全搜索，系統總是會(huì )第一個(gè)搜索QQ.exe所在目錄，從而把偽造的DLL加載到QQ.exe的進(jìn)程空間，而msimg32.dll的DllMain中可以做任何想做的事，破壞QQ程序已經(jīng)危害不小，如果做成病毒，木馬，后門(mén)的話(huà)，問(wèn)題就不是一般的嚴重了。
解決方法：
1. 可以看到xGraphic32.dll中只是用了msimg32.dll導出的一個(gè)函數AlphaBlend，所以可以嘗試將用到這個(gè)函數的地方自己實(shí)現，不過(guò)這個(gè)基于效率來(lái)說(shuō)，這個(gè)方案不是很可行。
2. 重寫(xiě)xGraphic32.dll，改用顯式的動(dòng)態(tài)鏈接，指定全路徑，這個(gè)好像是目前來(lái)說(shuō)最好的解決方案了。
3. 讓微軟把Msimg32.dll添加到Known Dlls列表中，這個(gè)是最最完美的解決方案，但是需要去和微軟溝通，希望下次看到系統的SP補丁包的時(shí)候會(huì )實(shí)現這個(gè)想法。
4 補充一個(gè)方法，在QQ.exe中判斷當前目錄是否存在msimg32.dll文件，如果存在就報錯，不存在正常啟動(dòng)。雖然這個(gè)方法比較笨，但是確實(shí)很有效的方法，但是如果QQ.exe被逆向的話(huà)，找到判斷代碼段并且修改的話(huà)，仍然能繼續劫持，不過(guò)這樣做的話(huà)就要承擔法律風(fēng)險責任了。
四、 補充話(huà)題：DLL劫持
可以回顧一下曾經(jīng)比較實(shí)用的WS2_32.dll一度成為DLL劫持的不二對象，之前微軟沒(méi)有把它列為Known Dlls，雖然說(shuō)這個(gè)DLL中函數比較多，但是如果想實(shí)行劫持的話(huà)，只需要將目標exe所引入的函數轉發(fā)就可以了。不過(guò)并不是所有的程序都需要調用這個(gè)動(dòng)態(tài)鏈接庫的，因為他是Windows socket函數簇的模塊。但是msimg就不一樣了，因為User32.DLL也引用了該函數，所以如果沒(méi)有把所有函數都轉發(fā)的的話(huà)，可能引起錯誤，好在Msimg32.dll只有四個(gè)函數，毫不費力就可以完全轉發(fā)，但是這恰恰是一個(gè)嚴重的漏洞產(chǎn)生原因。
