2019獨角獸企業(yè)重金招聘Python工程師標(biāo)準(zhǔn)>>>
藍(lán)屏沖突事件來歷 在2013年6月12日，也就是端午節(jié)當(dāng)天，微軟發(fā)布了6月例行補(bǔ)丁日的Windows/Office相關(guān)補(bǔ)丁，國內(nèi)各大安全廠商也向用戶及時推送 了這些補(bǔ)丁，而在補(bǔ)丁發(fā)布后，各大安全廠商、電腦廠商卻接到了大量的用戶反饋，說安裝了微軟KB2839229補(bǔ)丁后，導(dǎo)致系統(tǒng)藍(lán)屏，無法開機(jī)。
經(jīng)過對藍(lán)屏DUMP深入分析，可以明確這是金山系列軟件中的驅(qū)動程序，在掛鉤Windows內(nèi)核時處理不當(dāng)引發(fā)的藍(lán)屏問題，受影響的軟件包括金山毒 霸、金山衛(wèi)士、獵豹瀏覽器、驅(qū)動精靈（被金山收購）和WPS Office，受影響的驅(qū)動程序組件是：kisknl.sys(金山毒霸）、 KsDef.sys(金山衛(wèi)士）、knbdrv.sys(獵豹瀏覽器）、dgsafe.sys(驅(qū)動精靈）和WpsSafe.sys(WPS Office)。金山毒霸于12日下午1點緊急更新了新版驅(qū)動解決此問題，其他的產(chǎn)品升級狀況暫時還不清楚。
藍(lán)屏沖突事件Q&A 這里先給出一些關(guān)于此次藍(lán)屏事件的一些Q&A，再進(jìn)入技術(shù)分析的部分：
Q： 這次藍(lán)屏的技術(shù)原因簡單來說是什么？
A： 是由于金山系列軟件在掛鉤 Windows內(nèi)核時，強(qiáng)行跳過系統(tǒng)代碼進(jìn)行執(zhí)行，而跳過代碼的計算方式是使用硬編碼的方式導(dǎo)致的。因此只要操作系統(tǒng)代碼發(fā)生變更，金山系列軟件就會引發(fā)系統(tǒng)藍(lán)屏
Q： 金山的中國區(qū)論壇的官方置頂貼說此次藍(lán)屏是因為“微軟打補(bǔ)丁沒更新版本號導(dǎo)致的”，這是真的嗎？這次補(bǔ)丁藍(lán)屏是因為微軟的補(bǔ)丁存在問題嗎？
A： 這不是真的，微軟的補(bǔ)丁都會更新版本號，且此次藍(lán)屏同微軟更新補(bǔ)丁是否修改版本號無關(guān)，也不是微軟補(bǔ)丁的責(zé)任。
Q： 網(wǎng)上有人說360、電腦管家和瑞星等“國內(nèi)主流安全軟件”都會和這個補(bǔ)丁沖突發(fā)生藍(lán)屏，在這些安全軟件廠商論壇上也會看到有用戶反饋藍(lán)屏，這是真的嗎？
A： 這不是真的，除了金山外，360等安全軟件都未采用這種強(qiáng)行跳過系統(tǒng)代碼執(zhí)行的技術(shù)方案，不會同本次補(bǔ)丁沖突藍(lán)屏。其它廠商論壇上的藍(lán)屏反饋貼子，經(jīng)過溝通了解后，主要也都是同時安裝了金山系列軟件。
Q： 為什么有些金山用戶打補(bǔ)丁后并未藍(lán)屏？為什么我現(xiàn)在安裝了金山系列軟件，然后去打這個補(bǔ)丁沒出問題？
A： 金山毒霸于12日下午更新了新版驅(qū)動，因此更新驅(qū)動后再打補(bǔ)丁不會出現(xiàn)問題。另外，此補(bǔ)丁只影響32位系統(tǒng)，如果是64位系統(tǒng)的用戶無需安裝此補(bǔ)丁，因此也不會遇到藍(lán)屏問題。
Q： QQ電腦管家發(fā)布新聞?wù)fKB2839229、KB2839727這兩款補(bǔ)丁都有問題，會導(dǎo)致藍(lán)屏，這是真的嗎？
A： 由于金山軟件的問題，導(dǎo)致藍(lán)屏的只有KB2839229這一款補(bǔ)丁，KB2839727這款補(bǔ)丁是不存在的，這應(yīng)該新聞作者對補(bǔ)丁“KB2838727”之誤。
KB2838727這個補(bǔ)丁是IE瀏覽器積累性更新補(bǔ)丁，沒有升級內(nèi)核相關(guān)文件，不會導(dǎo)致藍(lán)屏
?
下面我們來具體分析下KB2839229這個補(bǔ)丁究竟更新了什么？為什么金山系列軟件在安裝了這個補(bǔ)丁后，會導(dǎo)致系統(tǒng)藍(lán)屏？
KB2839229補(bǔ)丁的來歷和分析 KB2839229這個補(bǔ)丁修復(fù)了由 Google的著名研究人員j00ru發(fā)現(xiàn)的一個微軟內(nèi)核信息泄漏安全漏洞CVE-2013-3136，這個漏洞是Windows系統(tǒng)內(nèi)核在處理頁面異常 的處理函數(shù)KiTrap0E中，由于針對系統(tǒng)內(nèi)核服務(wù)函數(shù)KiFastCallEntry的參數(shù)處理部分的特殊處理沒有考慮Ring3的請求的情況，而引 發(fā)的一個信息泄漏或拒絕服務(wù)安全漏洞。
J00ru在今年5月法國舉辦的安全大會NoSuchCon上公布了這一安全漏洞，并發(fā)表了一篇很有意思的論文：<<Abusing the Windows Kernel: How to Crash an Operating System With Two Instructions>>（如何只用兩條指令讓操作系統(tǒng)崩潰），這篇論文也被公開在他的技術(shù)博客上，對內(nèi)核安全感興趣的同學(xué)可以學(xué)習(xí)一 下：http://j00ru.vexillium.org/?p=1767
微軟6月的補(bǔ)丁KB2839229就是用來修復(fù)這個安全漏洞的，首先，微軟在修復(fù)后的Windows系統(tǒng)內(nèi)核:ntoskrnl.exe中，對 KiTrap0E函數(shù)做了一些修改，使用了一個新的名為KiPreprocessAccessViolation的函數(shù)，來統(tǒng)一處理針對特殊的內(nèi)核頁面異 常的處理，其中就包括出現(xiàn)漏洞的，針對KiFastCallEntry復(fù)制參數(shù)部分的特殊處理。同時，這個補(bǔ)丁也修改了部分 KiFastCallEntry的代碼，原先在 KiFastCallEntry復(fù)制參數(shù)之前，會有一個判斷是否是內(nèi)核模式的邏輯被優(yōu)化到KiFastCallEntry函數(shù)之外（這是微軟內(nèi)核的一個常 見編譯優(yōu)化手段），在新的版本中，由于新增了一個判斷，這部分邏輯被移動回了KiFastCallEntry函數(shù)內(nèi)，而正是這么一點點小小的正常改動，就 引發(fā)了金山系列軟件的藍(lán)屏。
我們來看一下補(bǔ)丁前和補(bǔ)丁后的ntoskrnl!KiFastCallEntry函數(shù)的對比
補(bǔ)丁前nt!KiFastCallEntry部分代碼（win7 SP1 x86）
02 mov???? edx, [edi+eax*4]
06 cmp???? esi, ds:_MmUserProbeAddress
09 test??? byte ptr [ebp+6Ch], 1
10 jz?????shortloc_43D8E5
?
補(bǔ)丁后nt!KiFastCallEntry部分代碼（win7 SP1 x86)
02 mov???? edx, [edi+eax*4]
06 test??? byte ptr [ebp+72h], 2
07 jnz????shortloc_435807???
08 test??? byte ptr [ebp+6Ch], 1
09 jz?????short_KiSystemServiceCopyArguments@0
10 cmp???? esi, ds:_MmUserProbeAddress
13 test??? byte ptr [ebp+6Ch], 1
14 jz?????shortloc_435831
?
對比之下就可以看到，從test byte ptr[ebp+72h],2開始，到j(luò)z short _KiSystemServiceCopyArguments的部分就是此次修改的代碼，這部分代碼(ebp+6c的檢查）本應(yīng)是在補(bǔ)丁前的那個 jnb?loc_43DAF5會去做檢查的（由于優(yōu)化，跳轉(zhuǎn)到函數(shù)之外，由于參數(shù)堆棧在內(nèi)核態(tài)區(qū)域，要判斷是否是內(nèi)核模式調(diào)用，如果不是會被拒絕），但這 里由于增加了ebp+72h的處理，因此一起被放回了代碼流中。
那么為什么這樣一個小小的修改，就引發(fā)金山系列軟件的驅(qū)動程序?qū)е孪到y(tǒng)藍(lán)屏，無法進(jìn)入系統(tǒng)呢？下面我們來分析金山驅(qū)動的掛鉤機(jī)制，解釋這個問題的原因。
金山驅(qū)動的分析 首先簡單介紹下KiFastCallEntry這個函數(shù)的背景，這是系統(tǒng)中所有的內(nèi)核服務(wù)分發(fā)的起點，當(dāng)用戶態(tài)的程序要調(diào)用一個內(nèi)核態(tài)的服務(wù)函數(shù)， 比如打開文件（通過 ZwCreateFile）或創(chuàng)建窗口(NtUserCreateWindowEx)，都會經(jīng)過這個函數(shù)點的分發(fā)，因此在這里進(jìn)行掛鉤，可以比較方便地針 對系統(tǒng)中的可疑程序的行為進(jìn)行監(jiān)控、分析和攔截。自360保險箱最早從2007年開始使用了針對KiFastCallEntry的掛鉤技術(shù)開始，國內(nèi)外大 量的安全軟件都開始通過掛鉤這個位置來實現(xiàn)主動防御、自我保護(hù)或沙箱等相關(guān)的安全功能，包括國內(nèi)的360，金山，QQ電腦管家，瑞星，國外的賽門鐵克， BitDefender等，都采用過類似的技術(shù)，當(dāng)然，各家的實現(xiàn)方式各有不同。
金山毒霸的KisKnl.sys驅(qū)動實現(xiàn)了一個特別的版本（金山系列的此次其他受影響驅(qū)動也類似，這里暫以KisKnl.sys為例進(jìn)行分析），該 驅(qū)動在掛鉤 KiFastCallEntry時，會搶在系統(tǒng)從用戶態(tài)堆棧復(fù)制參數(shù)之前，獲得執(zhí)行機(jī)會，然后強(qiáng)行跳過包括系統(tǒng)復(fù)制參數(shù)、相關(guān)檢查的邏輯，自己接管并實現(xiàn) 這部分系統(tǒng)代碼，然后再跳轉(zhuǎn)到后面的執(zhí)行代碼。
這個強(qiáng)行跳過系統(tǒng)代碼的特別的邏輯不僅奇怪，也存在著很多安全問題和藍(lán)屏隱患。筆者在2011年1月就曾向報告過一個金山毒霸2011中因為這個邏輯而引發(fā)的安全漏洞：CVE-2011-0515，被國外漏洞庫Secunia（http://secunia.com/advisories/42937）等和中國國家信息安全漏洞庫（http://www.cnnvd.org.cn/vulnerability/show/cv_id/2011010320?CNNVD-201101-320）收錄，此漏洞的原因就是因為金山的驅(qū)動跳走了這部分代碼，使得這部分代碼在復(fù)制堆棧參數(shù)時，不受KiTrap0E的異常保護(hù)，從而引發(fā)了安全漏洞，導(dǎo)致簡單的三條匯編指令，就可以在安裝了金山毒霸的系統(tǒng)上，觸發(fā)系統(tǒng)崩潰。
雖然金山后來修復(fù)了這個漏洞，但由于沒有修改這個錯誤的邏輯，仍留下了不小的性能隱患，這里不再贅述，下面就來看看引發(fā)這次補(bǔ)丁藍(lán)屏的金山驅(qū)動代碼的具體分析。
這里分析的 KisKnl.sys是金山毒霸修復(fù)補(bǔ)丁藍(lán)屏問題的上一個版本，數(shù)字簽名是2013年的5月30日。KisKnl.sys掛鉤 KiFastCallEntry的大概原理是，先通過SSDT HOOK掛鉤ZwDispalyString這個系統(tǒng)內(nèi)核服務(wù)，然后通過特殊的參數(shù)觸發(fā)這個函數(shù)的調(diào)用，由于在調(diào)用系統(tǒng)服務(wù)函數(shù)時，函數(shù)返回地址就是 KiFastCallEntry的函數(shù)中部，因此KisKnl.sys就此獲得了KiFastCallEntry這個未導(dǎo)出函數(shù)的中部位置的具體地址。
接著KisKnl.sys會通過一個簡易的二進(jìn)制搜索引擎，從KiFastCallEntry函數(shù)中部向上搜索一段被稱為 KiSystemServiceAccessTeb的位置附近的特征碼，在找到特征碼后，金山會根據(jù)系統(tǒng)的大版本號（這里的大版本號是指微軟大的產(chǎn)品版本 號，例如Windows XP, Windows7）來決定不同的硬編碼距離差值，通過這個距離差值，直接定位到跳過系統(tǒng)代碼后的位置，然后將其設(shè)為要跳轉(zhuǎn)的地址。
如我們上面分析的，微軟此次補(bǔ)丁，就恰好向KiFastCallEntry這部分代碼添加了4條指令，這就導(dǎo)致了金山原來以為雷打不動的大版本距離 差值發(fā)生了變化，從而導(dǎo)致定位到了錯誤的位置，最后掛鉤函數(shù)跳轉(zhuǎn)到了錯誤的代碼位置，引發(fā)系統(tǒng)藍(lán)屏。由于KiFastCallEntry是非常重要的系統(tǒng) 分發(fā)函數(shù)，因此這部分的代碼異常就導(dǎo)致了系統(tǒng)反復(fù)藍(lán)屏，無法進(jìn)入。
下面是對KisKnl.sys的這部分邏輯的反匯編，可以清楚的看到這部分邏輯：
01 .text:000310D7???????????????? mov???? eax, os_version
02 .text:000310DC???????????????? push??? esi
03 .text:000310DD???????????????? mov???? esi, callebx_return
04 .text:000310E3???????????????? add???? esi, 0FFFFFF38h
05 .text:000310E9???????????????? test??? eax, eax
06 .text:000310EB???????????????? jle???? loc_313C7
07 .text:000310F1???????????????? cmp???? eax, 3
08 .text:000310F4???????????????? jle???? loc_312F2
09 .text:000310FA???????????????? cmp???? eax, 4
10 .text:000310FD???????????????? jz????? loc_31251
11 .text:00031103???????????????? cmp???? eax, 5
12 .text:00031106???????????????? jz????? loc_311B3
13 .text:0003110C???????????????? cmp???? eax, 6
14 .text:0003110F???????????????? jnz???? loc_313C7
15 .text:00031115???????????????? lea???? eax, [ebp+code_offset]
16 .text:00031118???????????????? push??? eax
17 .text:00031119???????????????? push??? 27h
18 .text:0003111B???????????????? push??? offset KiAccessSystemTebCodeSpec
19 .text:00031120???????????????? push??? 0C8h
20 .text:00031125???????????????? push??? esi
21 .text:00031126???????????????? call??? code_search
22 .text:0003112B???????????????? test??? eax, eax
23 .text:0003112D???????????????? jz????? loc_3126B
24 .text:00031133???????????????? mov???? eax, [ebp+code_offset]
25 .text:00031136???????????????? lea???? ecx, [eax+esi+25h]
26 .text:0003113A???????????????? lea???? eax, [ecx+48h]
27 .text:0003113D???????????????? mov???? jump_cross_return_address, eax
?
從代碼中我們可以看到， KisKnl先是判斷系統(tǒng)版本號，然后在獲得的中部地址向上搜索獲得KiSystemServiceAccessTeb附近地址后，通過版本號硬編碼的偏移來決定跳轉(zhuǎn)返回的地址。
在新版本的KisKnl.sys在確定硬編碼偏移后，還會再判斷下代碼是否符合，暫時避免了這個問題，但仍留有繼續(xù)藍(lán)屏，或者保護(hù)失效的隱患。
國內(nèi)外使用類似技術(shù)的主流安全產(chǎn)品，不會采用硬編碼偏移的這種方式來確定跳轉(zhuǎn)地址，也不會采用強(qiáng)行跳走系統(tǒng)代碼這種不穩(wěn)定的做法，因此不存在同此補(bǔ)丁的沖突問題。
金山系列軟件發(fā)生這次的問題，主要還是開發(fā)人員技術(shù)經(jīng)驗不足，在技術(shù)方案選擇時沒有慎重考慮，在發(fā)生問題后沒有仔細(xì)考慮引發(fā)問題的方案的不足導(dǎo)致的。
內(nèi)核驅(qū)動程序的方案穩(wěn)定性決定著用戶系統(tǒng)與資料的穩(wěn)定與健全，開發(fā)人員都應(yīng)引以為戒，慎重對待和考慮技術(shù)方案。
轉(zhuǎn)載于:https://my.oschina.net/zhuzihasablog/blog/139114
總結(jié)
以上是生活随笔 為你收集整理的端午节蓝屏之谜：金山系列软件同微软KB2839229冲突技术分析 的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
如果覺得生活随笔 網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔 推薦給好友。
