在2018年1月底，F(xiàn)ortiGuard Labs團隊在微軟Windows中發(fā)現(xiàn)了一個遠程內(nèi)核崩潰漏洞，并按照Fortinet公司負責(zé)任的披露流程向微軟進行了報告。6月12日，微軟發(fā)布了一份包含此漏洞修復(fù)程序的公告，并將其標識為CVE-2018-1040。
這個漏洞存在于微軟Windows代碼完整性內(nèi)核模塊“ci.dll”中。所有流行的Windows版本都受到影響，包括Windows 10、Windows 7、Windows 8.1、Windows Server 2008、Windows Server 2012和Windows Server 2016。
漏洞可以通過在網(wǎng)站或SMB共享遠程下載一個精心制作的.DLL或.LIB文件到Windows上來觸發(fā)。當使用IE或Edge下載文件并保存時，將執(zhí)行Windows內(nèi)核指針解引用到無效地址。因此，會發(fā)生Windows Bugcheck（內(nèi)核崩潰）。在Windows 10上，系統(tǒng)重新啟動后，用戶登錄時會發(fā)生內(nèi)核崩潰。這導(dǎo)致Windows 10內(nèi)核的崩潰出現(xiàn)無限循環(huán)。
在這篇文章中，我將分享關(guān)于這個漏洞的詳細分析。
 
分析
要重現(xiàn)此遠程內(nèi)核崩潰漏洞，你可以在Windows 10上打開IE或Edge，輸入url http://192.168.0.111/poc.dll（它可以是托管PoC文件的任何URL），然后“在彈出窗口中選擇“保存。當保存文件poc.dll時，可以看到Windows 10 Bugcheck（內(nèi)核崩潰）。對于Windows 10中的內(nèi)核崩潰，內(nèi)核崩潰即使重新啟動也會繼續(xù)發(fā)生，這會導(dǎo)致Windows 10無法正常工作。對于用戶，系統(tǒng)可能需要重新安裝。
以下是發(fā)生崩潰時的調(diào)用堆棧。 

圖1.發(fā)生崩潰時的調(diào)用堆棧
從上面的調(diào)用堆棧輸出中，我們可以看到在調(diào)用函數(shù)“KERNELBASE!GetFileVersionInfoSizeExW”時會發(fā)生內(nèi)核崩潰，然后調(diào)用函數(shù)“KERNELBASE!LoadLibraryExW”。最后，它會導(dǎo)致一個完整的內(nèi)核崩潰。
當IE/Edge下載.dll或.lib文件并保存在磁盤上時，它將調(diào)用函數(shù)“KERNELBASE！GetFileVersionInfoSizeExW”來檢索.dll/.lib的版本信息。想要獲取.dll/.lib的版本信息，它會調(diào)用函數(shù)“KERNELBASE!LoadLibraryExW”以加載dwFlags等于0x22的.dll/.lib文件。在微軟MSDN中搜索，我們可以看到dwFlags 0x22是“LOAD_LIBRARY_AS_DATAFILE(0x00000002)”和“LOAD_LIBRARY_AS_IMAGE_RESOURCE(0x00000020)”的組合。因此，IE/Edge會將下載的.dll /.lib文件加載為資源.dll/.lib和數(shù)據(jù)文件以檢索相關(guān)信息。由于精心制作的poc.dll，在Windows 10發(fā)生內(nèi)核崩潰后，即使重新啟動也無法恢復(fù)系統(tǒng)。這是因為用戶登錄Windows時，會掃描IE/Edge臨時目錄中的.dll /.lib文件。
函數(shù)LoadLibraryExW加載精心制作的PoC文件poc.dll。當它處理SizeOfHeaders時，它會得到一個0x06的尺寸大小（這是一個精心制作的大小，正確的大小應(yīng)該是0x200）。在計算CI.dll中的函數(shù)CI!CipImageGetImageHash中的sha1散列塊大小時，會導(dǎo)致整數(shù)溢出。溢出的塊大小是0xfffffeb6。通過調(diào)用函數(shù)CI!SymCryptSha1AppendBlocks，計算得到溢出塊的大小為0xfffe7a。由于制作的sha1塊尺寸過大，導(dǎo)致大循環(huán)和內(nèi)核內(nèi)存讀訪問沖突。因此，會發(fā)生Windows Bugcheck（內(nèi)核崩潰）。 

圖2.包含精心制作的SizeOfHeaders的poc.dll
通過你想工程和跟蹤，我們可以看到函數(shù)_CipImageGetImageHash的調(diào)用導(dǎo)致一個sha1塊大小整數(shù)溢出。
 PAGE:85D15618 _CipImageGetImageHash@36 proc near ; CODE XREF:
......
PAGE:85D1571F mov edx, edi
PAGE:85D15721 mov ecx, [ebp+arg_4]
PAGE:85D15724 call _HashpHashBytes@12 ; HashpHashBytes(x,x,x)
PAGE:85D15729 lea edx, [esi+0A0h]
PAGE:85D1572F
PAGE:85D1572F loc_85D1572F: ; CODE XREF: CipImageGetImageHash(x,x,x,x,x,x,x,x,x)+CF↑j
PAGE:85D1572F mov edi, [ebp+arg_10]
PAGE:85D15732 mov eax, [edi+54h] ; -----> here [edi+54h] is obtained from poc.dll at offset 0x104, its value is 0x06.
PAGE:85D15735 sub eax, edx ; -----> here edx=83560150
PAGE:85D15737 add eax, [ebp+BaseAddress] ----> here [ebp+BaseAddress]=83560000
PAGE:85D1573A push eax ; ---------> So, after the above calculation, eax occurs integer subtraction overflow,result in eax=fffffeb6
PAGE:85D1573B mov ecx, [ebp+arg_4]
PAGE:85D1573E call _HashpHashBytes@12 ------> the function call chain finally results in a kernel crash
PAGE:85D15743 mov esi, [edi+54h] ;
PAGE:85D15746 mov [ebp+var_30], esi
In following function, an insufficient bounds check is performed:
.text:85D0368C @SymCryptHashAppendInternal@16 proc near
.text:85D0368C ; CODE XREF: SymCryptSha1Append(x,x,x)+10↑p
.text:85D0368C ; SymCryptMd5Append(x,x,x)+10↑p
.text:85D0368C
.text:85D0368C var_18 = dword ptr -18h
.text:85D0368C var_14 = dword ptr -14h
.text:85D0368C var_10 = dword ptr -10h
.text:85D0368C var_C = dword ptr -0Ch
.text:85D0368C var_8 = dword ptr -8
.text:85D0368C var_4 = dword ptr -4
.text:85D0368C Src = dword ptr 8
.text:85D0368C MaxCount = dword ptr 0Ch
.text:85D0368C
.text:85D0368C mov edi, edi
.text:85D0368E push ebp 
.text:85D0368F mov ebp, esp .
......
85D0372D mov ecx, [ebp+var_8]
.text:85D03730 mov edx, [ebp+var_18]
.text:85D03733 jmp short loc_85D0373B
.text:85D03735 ; ---------------------------------------------------------------------------
.text:85D03735.text:85D03735 loc_85D03735: ; CODE XREF: SymCryptHashAppendInternal(x,x,x,x)+46↑j
.text:85D03735 ; SymCryptHashAppendInternal(x,x,x,x)+52↑j
.text:85D03735 mov ecx, [ebp+Src]
.text:85D03738 mov [ebp+var_8], ecx
.text:85D0373B
.text:85D0373B loc_85D0373B: ; CODE XREF: SymCryptHashAppendInternal(x,x,x,x)+A7↑j
.text:85D0373B cmp esi, [edx+18h] ; ----> here [edx+18h] equals 40h, esi equals fffffe7a, due to unsigned integer comparison, the crafted block size is not found
.text:85D0373E jb short loc_85D03769
.text:85D03740 mov edi, [edx+1Ch]
.text:85D03743 lea eax, [ebp+var_C]
.text:85D03746 push eax
.text:85D03747 push esi
.text:85D03748 mov esi, [edx+0Ch]
.text:85D0374B add edi, ebx
.text:85D0374D mov ecx, esi
.text:85D0374F call ds:___guard_check_icall_fptr ; _guard_check_icall_nop(x)
.text:85D03755 mov edx, [ebp+var_8]
.text:85D03758 mov ecx, edi
.text:85D0375A call esi 
隨著sha1塊的溢出，它最終調(diào)用了以下函數(shù)：
.text:85D01060 @SymCryptSha1AppendBlocks@16 proc near ; CODE XREF: SymCryptSha1Result(x,x)+40↑p
......
.text:85D010A4 mov eax, [ebp+arg_0] -----> here eax gets the overflowed sha1 block size= 0xfffffe7a
.text:85D010A7 mov [esp+0D0h+var_B4], edi
.text:85D010AB mov [esp+0D0h+var_C4], ecx
.text:85D010AF cmp eax, 40h
.text:85D010B2 jb loc_85D02507
.text:85D010B8 mov [esp+0D0h+var_58], ecx
.text:85D010BC mov ecx, [esp+0D0h+var_C0]
.text:85D010C0 mov [esp+0D0h+var_54], ecx
.text:85D010C4 lea ecx, [edx+8] ;
.text:85D010C7 shr eax, 6 -------> the overflowed block size is used as the following loop function counter
.text:85D010CA mov [esp+0D0h+var_60], esi
.text:85D010CE mov [esp+0D0h+var_5C], edi
.text:85D010D2 mov [esp+0D0h+var_68], ecx ;
.text:85D010D6 mov [esp+0D0h+var_50], eax -----> here is the loop counter
......
.text:85D01359 ror edx, 2
.text:85D0135C mov ecx, [ecx+28h]
.text:85D0135F bswap ecx
.text:85D01361 mov [esp+0D0h+var_6C], ecx
.text:85D01365 mov ecx, eax
.text:85D01367 rol ecx, 5
.text:85D0136A mov eax, edi
.text:85D0136C add ecx, [esp+0D0h+var_6C]
.text:85D01370 xor eax, edx
.text:85D01372 and eax, [esp+0D0h+var_C0]
.text:85D01376 xor eax, edi
.text:85D01378 add edi, 5A827999h
.text:85D0137E add eax, ecx
.text:85D01380 mov ecx, [esp+0D0h+var_68]
.text:85D01384 add eax, esi
.text:85D01386 mov esi, [esp+0D0h+var_C0]
.text:85D0138A mov [esp+0D0h+var_84], eax
.text:85D0138E ror esi, 2
.text:85D01391 mov ecx, [ecx+2Ch] ----> after a large loop call, here it results in a read access violation, so the bugcheck (kernel crash) occurs 
.text:85D01394 bswap ecx
.text:85D01396 mov [esp+0D0h+var_9C], ecx
.......
.text:85D024DD mov ecx, [esp+0D0h+var_68]
.text:85D024E1 mov [esp+0D0h+var_54], eax
.text:85D024E5 add ecx, 40h ----> memory access pointer increases 0x40 in each loop
.text:85D024E8 mov [esp+0D0h+var_C0], eax
.text:85D024EC mov eax, [ebp+arg_0]
.text:85D024EF sub eax, 40h
.text:85D024F2 mov [esp+0D0h+var_68], ecx
.text:85D024F6 sub [esp+0D0h+var_50], 1 ------> here the loop counter decreases by 1, not equaling 0, to continue the loop. Due to the overflowed large sha1 block size, here a large loop is executed.
.text:85D024FE mov [ebp+arg_0], eax
.text:85D02501 jnz loc_85D010DD
.text:85D02507
從上面的分析中可以看出，遠程內(nèi)核崩潰的根本原因是LoadLibraryEx函數(shù)無法正確解析精心制作的.dll/.lib文件作為資源和數(shù)據(jù)文件。當poc.dll包含精心制作的SizeOfHeaders值0x06（正確的值應(yīng)為0x200）位于PoC文件中的偏移量0x104處時，會發(fā)生整數(shù)溢出。
精心制作的大小值會導(dǎo)致計算錯誤的sha1塊大小（它會變成一個負值）。由于邊界檢查不足，sha1計算函數(shù)進入一個較大的循環(huán)，這會導(dǎo)致內(nèi)存讀取訪問沖突。最后，發(fā)生系統(tǒng)Bugcheck（內(nèi)核崩潰）。
 
解決方案
所有易受攻擊的微軟Windows用戶都被鼓勵升級到最新的Windows版本或應(yīng)用最新的補丁。此外，已經(jīng)部署了Fortinet IPS解決方案的組織已經(jīng)通過以下簽名保護不受此漏洞影響：
MS.Windows.Code.Integrity.Module.DoS