亚洲日本免费-啊轻点灬太粗太长了三男一女-麻豆av电影在线观看-日韩一级片毛片|www.grbbt.com

　　微軟在北京時(shí)間2015年1月22日，公布了其新一代操作系統(tǒng)Windows 10的新技術(shù)預(yù)覽版，并在隨后的北京時(shí)間1月24日向公眾開放了該預(yù)覽版本的下載（Build：9926）。在這個(gè)新的Windows10預(yù)覽版中，內(nèi)核版本直接從6.4提升到了10.0，同時(shí)也帶來了一些新的產(chǎn)品形態(tài)和用戶體驗(yàn)上的諸多改進(jìn)。

　　作為國際頂尖的安全廠商，360除了在第一時(shí)間為使用Windows 10新預(yù)覽版的用戶提供安全防護(hù)，也在同時(shí)關(guān)注新操作系統(tǒng)中引入的新安全特性。

　　微軟從Windows 8開始，就為其新的操作系統(tǒng)不斷引入了很多新的安全特性，包括零頁禁用、高熵隨機(jī)化、執(zhí)行流保護(hù)（Control Flow Guard ， CFG）、管理模式執(zhí)行保護(hù)（Superior Mode Execution Prevention， SMEP）等等，對(duì)Windows平臺(tái)上的應(yīng)用和內(nèi)核漏洞利用明顯地提高了門檻。這次Windows 10的新技術(shù)預(yù)覽版又為操作系統(tǒng)加入了什么樣新的保護(hù)呢？

　　在拿到內(nèi)核并進(jìn)行分析之后，首先進(jìn)入筆者視線的就是本文將要介紹的，Windows 10預(yù)覽版中對(duì)于字體的安全防護(hù)的兩項(xiàng)增強(qiáng)。

　　這里要提到的是，本文在完成前（北京時(shí)間1月24日早上9點(diǎn)~11點(diǎn)左右），國外的一些安全研究人員，包括CrowdStrike公司的Alex Ionescu（@aionescu）和Google公司的Kostya Kortchinsky（@crypt0ad），也都同時(shí)發(fā)現(xiàn)并在Twitter上提到了這兩項(xiàng)增強(qiáng)相關(guān)的關(guān)鍵字。

　　這里本文將帶讀者第一時(shí)間深入地分析Windows 10字體防護(hù)增強(qiáng)的實(shí)現(xiàn)和策略，了解其中的來龍去脈。

　　內(nèi)核字體引擎安全問題

　　由于諸多歷史原因，Windows的內(nèi)核模式字體引擎長期以來是Windows操作系統(tǒng)內(nèi)核中典型的復(fù)雜程度高而代碼安全質(zhì)量并不高的組件。出于字體引擎性能的考慮，微軟也不得不將其一直放在內(nèi)核模式。因此，一旦Windows內(nèi)核中的字體引擎出現(xiàn)安全漏洞，漏洞攻擊代碼就可以在用戶瀏覽網(wǎng)頁或文檔中的遠(yuǎn)程字體文件時(shí)，直接在Windows內(nèi)核中執(zhí)行，可以完全繞過幾乎所有的安全防護(hù)機(jī)制，殺傷力相當(dāng)大。

　　360的安全研究人員王宇對(duì)于內(nèi)核字體引擎的安全歷史和安全漏洞進(jìn)行了深入的研究。他將一些技術(shù)成果公開在國際安全會(huì)議Syscan360 2012（http：//www.syscan360.org/achive_2012_speech.html）和Blackhat2014（https：//www.blackhat.com/us-14/briefings.html#understanding-tocttou-in-the-windows-kernel-font-scaler-engine）上。對(duì)相關(guān)技術(shù)有興趣的讀者可以深入地學(xué)習(xí)一下。

　　歷史上微軟修復(fù)的內(nèi)核字體漏洞并不少，但最出名的，也是打破了字體漏洞神秘感的，可能就要數(shù)2011年被安全廠商披露的感染伊朗等國家的震網(wǎng)二代”Duqu”病毒。

　　該病毒是利用Windows內(nèi)核字體引擎中的一處漏洞（CVE-2011-3402），將利用該漏洞的、命名為嗜血法醫(yī)Dexter的字體文件嵌入到word文檔中，當(dāng)用戶打開word文檔、觸發(fā)字體加載，惡意代碼就直接進(jìn)入內(nèi)核模式運(yùn)行。

　　這應(yīng)該是首次被公開披露的字體漏洞用于真實(shí)的APT攻擊的案例。其后，該漏洞還被一些Exploit Kit改造為通過網(wǎng)頁瀏覽器進(jìn)行攻擊的版本，開始大范圍的傳播和攻擊。

　　在今年的10月，國外安全公司Fireeye也披露了他們新發(fā)現(xiàn)的被用于真實(shí)的APT攻擊的字體漏洞：（CVE-2014-4148）（https：//www.fireeye.com/blog/threat-research/2014/10/two-targeted-attacks-two-new-zero-days.html）。這個(gè)漏洞攻擊巧妙地利用字體引擎中一處整數(shù)符號(hào)問題，實(shí)現(xiàn)在瀏覽嵌入了字體的文檔或網(wǎng)頁時(shí)，直接從內(nèi)核模式執(zhí)行惡意代碼，繞過系統(tǒng)中的安全防護(hù)機(jī)制，安裝惡意程序。

　　無論是白帽子安全研究人員還是可能具備國家級(jí)背景的高級(jí)黑客，針對(duì)Windows字體引擎安全問題的深入挖掘，都將這一攻擊面的危險(xiǎn)狀況更多地暴露出來。微軟在修復(fù)漏洞的同時(shí)，也在計(jì)劃著一些更通用的解決辦法。

　　在2014年的8月補(bǔ)丁日，微軟在針對(duì)字體引擎內(nèi)核漏洞的補(bǔ)丁中，就引入了一項(xiàng)針對(duì)字體緩存機(jī)制的安全優(yōu)化，來緩和通過字體緩存進(jìn)行的某些字體漏洞攻擊手法。這次Windows 10新預(yù)覽版中的這兩項(xiàng)改進(jìn)，則是微軟針對(duì)字體漏洞攻擊緩和的另一次嘗試。

　　Windows 10字體安全防護(hù)

　　下面筆者就來詳細(xì)介紹下這次引入的改進(jìn)。

　　第一項(xiàng)增強(qiáng)：非系統(tǒng)字體禁用策略

　　從Windows 8開始，微軟引入了一個(gè)新的API： SetProcessMitigationPolicy。該API通過最終調(diào)用NtSetInformationProcess（ProcessMitigationPolicy），設(shè)置進(jìn)程EPROCESS對(duì)象中Flags（Flags2，F(xiàn)lags3）域中的某些位，來打開/關(guān)閉進(jìn)程粒度的一些漏洞緩和機(jī)制的開關(guān)。

　　這些緩和機(jī)制包括強(qiáng)制DEP/ALSR、零頁內(nèi)存禁用、句柄強(qiáng)制檢查等。除了通過這個(gè)API，相關(guān)的開關(guān)也可以通過父進(jìn)程繼承、StartupInfo（Process Thread Attributes）、IEFO和全局緩和選項(xiàng)等方式來控制。

　　本次引入的一個(gè)新的緩和選項(xiàng)被稱為ProcessFontDisablePolicy。在對(duì)進(jìn)程設(shè)置這個(gè)緩和策略后，表現(xiàn)在EPROCESS->Flags3.DisableNonSystemFonts這個(gè)標(biāo)記上，同時(shí)還有AuditNonSystemFontLoading作為輔助選項(xiàng)。

　　這個(gè)選項(xiàng)的功能顧名思義，就是針對(duì)進(jìn)程禁止加載非系統(tǒng)的字體，AuditNonSystemFontLoading則是審計(jì)記錄非系統(tǒng)字體的加載。

　　那么系統(tǒng)是如何實(shí)現(xiàn)該機(jī)制的呢？這里我們就要看看內(nèi)核字體引擎了。在Windows 10中，內(nèi)核字體引擎主要位于Win32k內(nèi)核驅(qū)動(dòng)的完整版本： win32full.sys中。

　　桌面內(nèi)核引擎win32k提供了多個(gè)系統(tǒng)調(diào)用接口允許用戶模式加載字體到內(nèi)核字體引擎中，包括NtGdiAddFontResourceEx，NtGdiAddFontMemResourceEx等等。在內(nèi)核字體引擎內(nèi)部根據(jù)不同的場(chǎng)景，主要是使用以下四個(gè)函數(shù)來實(shí)現(xiàn)字體文件的加載處理的：

　　1 PUBLIC_PFTOBJ：：bLoadFonts

　　2 PUBLIC_PFTOBJ：：hLoadMemFonts

　　3 PUBLIC_PFTOBJ：：bLoadRemoteFonts

　　4 DEVICE_PFTOBJ：：bLoadFonts

　　這四個(gè)函數(shù)是內(nèi)核字體引擎在不同場(chǎng)景下加載字體文件的關(guān)鍵函數(shù)。在這些函數(shù)中，內(nèi)核將分配（或直接使用）關(guān)鍵的字體文件視圖對(duì)象（FontFileView），并調(diào)用vLoadFontFileView函數(shù)來加載字體文件視圖對(duì)象，將其描述的字體文件數(shù)據(jù)映射到內(nèi)核內(nèi)存中，并進(jìn)行解析和處理，以供后面渲染使用。

　　本次Windows 10新預(yù)覽版就在這些函數(shù)中調(diào)用vLoadFontFileView加載字體文件視圖對(duì)象之前，進(jìn)行檢查。

　　01 …

　　02 FontLoadingOptions = GetCurrentProcessFontLoadingOption()；

　　03

　　04 if ( FontLoadingOptions == 2 )

　　05 {

　　06   NonSystemFontPath = GetFirstNonSystemFontPath(FontFilePathNames， FontFileCount)；

　　07   if ( NonSystemFontPath )

　　08   {

　　09     LogFontLoadAttempt(FONT_LOAD_NORMAL， NonSystemFontPath， TRUE)；

　　10     return FALSE；

　　11   }

　　12 }

　　13 else if ( FontLoadingOptions == 1 )

　　14 {

　　15   NonSystemFontPath = GetFirstNonSystemFontPath(FontFilePathNames， FontFileCount)；

　　16   if ( NonSystemFontPath )

　　17     LogFontLoadAttempt(FONT_LOAD_NORMAL， NonSystemFontPath， FALSE)； // log only

　　18 }

　　19

　　20 …

　　這里我們可以看到代碼首先通過GetCurrentProcessFontLoadingOption調(diào)用獲取字體加載緩和的選項(xiàng)。

　　該函數(shù)實(shí)際是通過NtQueryInformationProcess（ProcessMitigationPolicy）獲得_PROCESS_MITIGATION_FONT_DISABLE_POLICY結(jié)構(gòu)。

　　在結(jié)構(gòu)中，bit0為DisableNonSystemFonts，bit1為AuditNonSystemFontLoading，接著此結(jié)構(gòu)被轉(zhuǎn)換成下面三個(gè)選項(xiàng)值：

　　0： 不審計(jì)、不禁用

　　1：審計(jì)、不禁用

　　2：審計(jì)并禁用

　　然后，系統(tǒng)會(huì)調(diào)用GetFirstNonSystemFontPath函數(shù)解析要加載的字體文件列表（可能是多個(gè)文件）。該函數(shù)分別通過IoCreateFile得到這些文件的文件句柄，再通過句柄得到文件對(duì)象的完整路徑，最后同系統(tǒng)字體目錄（%Systemroot%Fonts）進(jìn)行對(duì)比。

　　如果待加載的字體列表中存在非系統(tǒng)字體目錄下的字體文件，那么系統(tǒng)會(huì)首先調(diào)用LogFontAttempt函數(shù)，通過ETW機(jī)制記錄到日志中。

　　該函數(shù)的第一個(gè)參數(shù)為觸發(fā)字體加載的類型：

　　1 0： LoadPublicFonts

　　2 1： LoadMemFonts

　　3 2： LoadRemoteFonts

　　4 3： LoadDeviceFonts

　　第二個(gè)參數(shù)是觸發(fā)的字體路徑。

　　第三個(gè)參數(shù)是是否要對(duì)該字體拒絕加載。

　　接著，系統(tǒng)會(huì)根據(jù)進(jìn)程緩和選項(xiàng)的設(shè)置，決定對(duì)于這種情況，是僅審計(jì)記錄，還是要拒絕這個(gè)字體的加載。

　　對(duì)于調(diào)用時(shí)不含有直接的字體文件路徑的LoadMemFonts/LoadRemoteFonts/LoadDeviceFonts的情況，內(nèi)核將不會(huì)判斷字體路徑，如果在緩和選項(xiàng)設(shè)置了禁止非系統(tǒng)字體加載，則會(huì)禁用這些接口在所有情況下的字體加載并進(jìn)行審計(jì)。

　　從微軟公開的Windows 10技術(shù)預(yù)覽版來看，這項(xiàng)防護(hù)開關(guān)并沒有對(duì)一些關(guān)鍵應(yīng)用如Internet Explorer、內(nèi)置的PDF瀏覽器等默認(rèn)開啟。

　　從目前的功能設(shè)計(jì)看來，該功能更像是為特定的企業(yè)用戶提供的防止高級(jí)攻擊的安全措施。尤其是針對(duì)字體加載的審計(jì)功能，可以幫助IT管理人員快速定位可能的高級(jí)威脅攻擊。

　　值得一提的是，在360的XP盾甲的2.0中，我們就引入了同Windows10本次更新加入的字體禁止策略類似的機(jī)制。通過XP盾甲的隔離引擎機(jī)制，我們將系統(tǒng)中的字體同沙箱隔離環(huán)境中的字體隔離開來，使得沙箱隔離環(huán)境中的字體無法加載到內(nèi)核中，而隔離環(huán)境之外的字體在隔離環(huán)境內(nèi)則不受影響，達(dá)到了和Windows10這項(xiàng)防護(hù)類似的漏洞防御效果。

　　在XP盾甲4.0的產(chǎn)品中，我們則引入了更強(qiáng)的內(nèi)核字體引擎鎖定機(jī)制，針對(duì)內(nèi)核字體引擎的攻擊防護(hù)強(qiáng)度又上了一個(gè)臺(tái)階。360一年前設(shè)計(jì)的XP盾甲防護(hù)機(jī)制同微軟公布的新一代操作系統(tǒng)中的新防護(hù)措施的不謀而合，也從側(cè)面印證了360在漏洞防護(hù)研究方面的探索。

　　第二項(xiàng)增強(qiáng)：隔離的用戶模式字體引擎

　　在Windows 10的新技術(shù)預(yù)覽版中，針對(duì)內(nèi)核字體引擎的另一項(xiàng)引人注意的重大改進(jìn)是“用戶模式字體驅(qū)動(dòng)”（User Mode Font Driver，UMFD）機(jī)制。

　　就像前面我們說到的，位于內(nèi)核模式的字體引擎的一旦被突破，攻擊者通過精巧的數(shù)據(jù)構(gòu)造可以直接從遠(yuǎn)程獲得內(nèi)核代碼執(zhí)行的能力，危險(xiǎn)極大。

　　同時(shí)，由于字體引擎在內(nèi)核中運(yùn)行，因此針對(duì)字體引擎的修改也必須非常謹(jǐn)慎，稍有不慎就可能引發(fā)大面積的藍(lán)屏或應(yīng)用程序異常。

　　關(guān)于修改內(nèi)核字體引擎帶來的副作用，眼前就有典型的案例：在今年8月的補(bǔ)丁日中，微軟的KB2982791補(bǔ)丁為了修復(fù)字體引擎中的安全漏洞，修改了內(nèi)核字體緩存引擎。結(jié)果，這一改動(dòng)中存在的兼容問題不幸引發(fā)了大面積的用戶Windows系統(tǒng)啟動(dòng)即藍(lán)屏的問題。該問題遭到了大量用戶和媒體的指責(zé)，微軟不得不宣布將該補(bǔ)丁撤回重發(fā)。

　　在這個(gè)Windows 10技術(shù)預(yù)覽版中，微軟首次建立了用戶模式和內(nèi)核模式的字體引擎交互機(jī)制，將內(nèi)核字體引擎中的多個(gè)字體驅(qū)動(dòng)引擎移植到用戶模式，使得字體引擎能夠部分在隔離的用戶模式進(jìn)程中運(yùn)行，同時(shí)也保留了內(nèi)核模式字體引擎驅(qū)動(dòng)的機(jī)制，盡量將可能出現(xiàn)安全漏洞的渲染引擎放到用戶模式，同時(shí)使用一些內(nèi)核預(yù)先加載、內(nèi)核/用戶模式交互的方式，減少這種模式對(duì)于性能的損耗。

　　在這套機(jī)制應(yīng)用后，如果相關(guān)的字體引擎代碼出現(xiàn)安全漏洞，攻擊者只能控制被隔離的用戶模式字體驅(qū)動(dòng)宿主，無法通過字體漏洞直接控制操作系統(tǒng)內(nèi)核。而修復(fù)相關(guān)漏洞的成本和可能的風(fēng)險(xiǎn)，也將大大降低。

　　這里筆者將主要介紹這套新的UMFD機(jī)制的運(yùn)作原理和一些關(guān)鍵細(xì)節(jié)。限于時(shí)間和篇幅的原因，關(guān)于UMFD很多具體實(shí)現(xiàn)、實(shí)際性能狀況、實(shí)際漏洞隔離效果等，這里無法詳盡地覆蓋到，感興趣的讀者可以去深入逆向、分析和測(cè)試相關(guān)的代碼和功能來發(fā)現(xiàn)更多的內(nèi)容，也可以在本Blog同筆者討論。

　　在前面一節(jié)中，我們介紹了，*：：Load*Fonts系列函數(shù)將使用vLoadFontFileView加載字體文件視圖對(duì)象，而這節(jié)要介紹的增強(qiáng)里的一個(gè)關(guān)鍵點(diǎn)就在vLoadFontFileView函數(shù)中，在Windows10 build 9926中，該函數(shù)的偽代碼如下：

　　01 void vLoadFontFileView(…)

　　02 {

　　03    *(pchecksum + 4) = 0；

　　04    *pchecksum = 0；

　　05

　　06    if ( gbNetworkFontsLoaded && gbAttemptedEnableEUDC && gbFntCacheClosed )

　　07    {

　　08       UmfdLoadFontFileView(

　　09                            FontPathName，

　　10                            pfileview，

　　11                            filecount，

　　12                            pview，

　　13                            countview，

　　14                            pdesignvector，

　　15                            hff，

　　16                            devlist)；

　　17                            }

　　18     else

　　19     {

　　20       KmfdLoadFontFileView(

　　21                            FontPathName，

　　22                            cwc，

　　23                            pfileview，

　　24                            filecount，

　　25                            pview，

　　26                            countview，

　　27                            pdesignvector，

　　28                            countdv，

　　29                            hff，

　　30                            devlist，

　　31                            pchecksum)；

　　32                            }

　　33     }

　　對(duì)比上個(gè)公開發(fā)布的Windows 10技術(shù)預(yù)覽版（Build 9879）我們可以看到，vLoadFontFileView根據(jù)多個(gè)開關(guān)進(jìn)行判斷，分別執(zhí)行到UmfdLoadFontFileView和KmfdLoadFontFileView這兩種情況。

　　而我們仔細(xì)觀察下KmfdLoadFontFileView就可以發(fā)現(xiàn)，它的代碼和9879中原有的vLoadFontFileView的代碼是非常相似的。

　　因此我們可以推測(cè)：在Build9926中，微軟針對(duì)gbNetworkFontsLoaded （有遠(yuǎn)程字體加載） + gbAttemptedEnableEUDC（曾調(diào)用過NtGdiEnableEUDC啟用EUDC) + gbFntCacheClosed（系統(tǒng)啟動(dòng)字體已經(jīng)加載到緩存中）的情況下， 就會(huì)進(jìn)入名為UmfdLoadFontFileView的分支來進(jìn)行用戶模式字體加載，否則就使用KmfdLoadFontFileView，即原有的vLoadFontFileView邏輯來加載字體。

　　根據(jù)我們的推測(cè)，UmfdLoadFontFileView應(yīng)該就是用戶模式字體驅(qū)動(dòng)（UMFD）的字體加載函數(shù)。如何證實(shí)這點(diǎn)呢？該函數(shù)又是如何同用戶模式的字體驅(qū)動(dòng)引擎交互的呢？

　　我們繼續(xù)進(jìn)入U(xiǎn)mfdLoadFontFileView函數(shù)，看看他的實(shí)現(xiàn)。

　　在該函數(shù)中，我們可以看到它會(huì)調(diào)用UmfdHostLifeTimeManager：：EnsureUmfdHost，該函數(shù)是用戶模式的字體引擎宿主的生命周期管理函數(shù)，用于確保用戶模式的字體引擎宿主客戶端存在。

　　我們查看這個(gè)函數(shù)，可以發(fā)現(xiàn)該函數(shù)的關(guān)鍵點(diǎn)是：如果Winlogon進(jìn)程存在，那么使用PostWinlogonMessage發(fā)送一條1033的消息，并等待UmfdHostLifeTimeManager：：s_WinlogonCallbackEvent事件觸發(fā)。

　　PostWinlogonMessage函數(shù)實(shí)現(xiàn)在win32kbase.sys中，實(shí)際是調(diào)用msrpc.sys導(dǎo)出的相關(guān)LPC/RPC函數(shù)給winlogon.exe的LPC接口發(fā)送內(nèi)核模式LPC消息。

　　winlogon.exe則會(huì)在WMsgKMessageHandler函數(shù)中接收這個(gè)消息。這個(gè)1033號(hào)消息實(shí)際的作用，就是去加載用戶模式的字體驅(qū)動(dòng)客戶端fontdrvhost.exe。

　　在收到1033號(hào)消息后，Winlogon會(huì)使用LaunchUmfdHostWithRestrictedToken函數(shù)，通過WTSQueryUserToken獲取當(dāng)前登錄的用戶token句柄。

　　接著，它使用SetTokenInformation（TokenIntegrityLevel）將token的完整性級(jí)別設(shè)置為Low。

　　最后，它通過CreateProcessAsUser，使用這個(gè)受限的token來創(chuàng)建fontdrvhost.exe（默認(rèn)位于%systemroot%system32下）進(jìn)程。

　　接下來的一個(gè)關(guān)鍵步驟是通知UMFD的驅(qū)動(dòng)部分，在UMFD的內(nèi)核部分引擎中注冊(cè)fontdrvhost.exe這個(gè)用戶模式客戶程序。

　　這里使用的是gdi32！NamedEscape函數(shù)，該函數(shù)實(shí)際上是通過調(diào)用NtGdiExtEscape來實(shí)現(xiàn)同win32k內(nèi)核驅(qū)動(dòng)通訊的。

　　NtGdiExtEscape過去被win32k內(nèi)核部分用于同gdi32進(jìn)行一些內(nèi)核/用戶模式交互，在新的Windows10預(yù)覽版中，該函數(shù)被umfd使用來進(jìn)行umfd的相關(guān)內(nèi)核交互，是UMFD的內(nèi)核/用戶模式交互基礎(chǔ)。

　　在創(chuàng)建了fontdrvhost進(jìn)程后，Winlogon通過NamedEscape->NtGdiExtEscape將創(chuàng)建的進(jìn)程PID發(fā)送給內(nèi)核。

　　在新的NtGdiExtEscape中，內(nèi)核檢測(cè)到發(fā)起該調(diào)用的進(jìn)程是winlogon進(jìn)程，就識(shí)別傳入的參數(shù)，通過UmfdHostLifeTimeManager：：InitializeUmfdAndRegisterHost獲得該進(jìn)程的進(jìn)程對(duì)象，將其注冊(cè)為UMFD的宿主客戶端，并設(shè)置我們前面提到的UmfdHostLifeTimeManager：：s_WinlogonCallbackEvent事件，來通知UMFD客戶端已經(jīng)準(zhǔn)備完畢。

　　在注冊(cè)為UMFD的宿主客戶端后，fontdrvhost.exe就可以通過NamedEscape->NtGdiExtEscape同內(nèi)核模式進(jìn)行通訊。在這個(gè)系統(tǒng)調(diào)用的實(shí)現(xiàn)里，會(huì)識(shí)別如果是UMFD的宿主進(jìn)程進(jìn)行的調(diào)用，則進(jìn)入一個(gè)UMFD的專用通訊函數(shù)：UmfdDispatchEscape。

　　在UmfdDispatchEscape中，內(nèi)核提供了一些用戶模式字體驅(qū)動(dòng)客戶端所需要的內(nèi)核-用戶模式數(shù)據(jù)交互、文件映射與訪問接口等，這個(gè)后面我們會(huì)提到。

　　上面我們說到的是UMFD用戶模式客戶端的創(chuàng)建以及它同內(nèi)核模式部分通訊的過程。

　　接下來，我們回到剛才說的vLoadFontFileView函數(shù)過程。上面我們說到在注冊(cè)用戶模式字體宿主進(jìn)程后，內(nèi)核會(huì)置UmfdHostLifeTimeManager：：s_WinlogonCallbackEvent事件來通知UMFD用戶模式部分已經(jīng)開始工作并使得字體加載過程繼續(xù)下去。

　　那么接下來，內(nèi)核就開始進(jìn)行實(shí)際的用戶模式字體加載，通過調(diào)用PDEVOBJ：：LoadFontFile，實(shí)際上內(nèi)核會(huì)Attach到CSRSS進(jìn)程上，并調(diào)用UMFD的字體加載接口函數(shù)：UmfdLoadFontFile來完成字體加載。

　　UmfdLoadFontFile是UMFD的接口列表UmfdDDIs中用于處理UMFD字體實(shí)際加載工作的接口函數(shù)。它的核心功能是通UmfdClientSendAndWaitForCompletion函數(shù)將UMFD請(qǐng)求插入U(xiǎn)MFD工作隊(duì)列中，并通知UMFD的用戶模式部分處理隊(duì)列中的數(shù)據(jù)。

　　除了UmfdLoadFontFile外，UmfdDDIs這個(gè)接口列表中還包含了同內(nèi)核模式字體接口一一對(duì)應(yīng)的諸如UmfdQueryFontData、UmfdQueryFontTree、UmfdGetTrueTypeFile等字體相關(guān)的重要接口。

　　當(dāng)對(duì)應(yīng)的內(nèi)核模式接口被調(diào)用時(shí)，實(shí)際也是由這些接口函數(shù)使用UmfdClientSendAndWaitForCompletion發(fā)送請(qǐng)求到UMFD用戶模式處理隊(duì)列中，通知用戶模式客戶端來完成實(shí)際的字體工作的。

　　用戶模式字體驅(qū)動(dòng)客戶端宿主fontdrvhost.exe啟動(dòng)后，則會(huì)建立一個(gè)ServerRequestLoop線程，該線程通過NamedEscape(NtGdiExtEscape）(Dispatch id = 0 )來同內(nèi)核交互.

　　當(dāng)NameEscape傳遞的Dispatch id = 0 時(shí)，實(shí)際內(nèi)核執(zhí)行的對(duì)應(yīng)是UmfdEscSendCompleteWaitReceive函數(shù)。該函數(shù)同UmfdClientSendAndWaitForCompletion是成對(duì)的，用于“接收”通過UmfdClientSendAndWaitForCompletion“發(fā)送”到隊(duì)列的請(qǐng)求數(shù)據(jù)。

　　在宿主從內(nèi)核獲得字體操作請(qǐng)求數(shù)據(jù)返回用戶模式后，用戶模式字體驅(qū)動(dòng)宿主再使用DispatchRequest函數(shù)分發(fā)到內(nèi)核的字體處理請(qǐng)求到各個(gè)用戶模式字體驅(qū)動(dòng)接口中。

　　這些用戶模式字體驅(qū)動(dòng)目前也都是編譯在fontdrvhost.exe這個(gè)進(jìn)程的代碼中的，主要有ttf字體驅(qū)動(dòng)、bmf字體驅(qū)動(dòng)和vtf字體驅(qū)動(dòng)等相關(guān)的處理代碼。

　　在處理內(nèi)核字體請(qǐng)求時(shí)，DispatchRequest會(huì)根據(jù)請(qǐng)求數(shù)據(jù)中指定的設(shè)備和指定的請(qǐng)求類型（QueryFontData，LoadFontFile…)來選擇不同的字體驅(qū)動(dòng)處理例程進(jìn)行最終的字體處理過程。

　　值得一提的是，在用戶模式字體引擎中，包括針對(duì)字體虛擬機(jī)的指令實(shí)現(xiàn)部分（itrp_*函數(shù)），也是在用戶模式中實(shí)現(xiàn)的。

　　最近幾年被曝光用于真實(shí)攻擊的內(nèi)核模式字體漏洞，都是在特定的itrp_*函數(shù)處理數(shù)據(jù)中發(fā)生的安全問題，也都需要依賴itrp_*函數(shù)來操縱內(nèi)核數(shù)據(jù)來實(shí)現(xiàn)最終的漏洞攻擊。這項(xiàng)新的增強(qiáng)將這些函數(shù)隔離在低完整性級(jí)別的受限用戶模式進(jìn)程中，顯然極大地提高了這類漏洞的攻擊難度和利用門檻。

　　簡(jiǎn)單總結(jié)來說，UMFD這套機(jī)制實(shí)際上就是通過在內(nèi)核并行純內(nèi)核模式字體引擎和需交互的用戶模式字體引擎兩套系統(tǒng)。在系統(tǒng)啟動(dòng)過程中使用性能更好的內(nèi)核模式加載不會(huì)有安全問題的、已注冊(cè)的系統(tǒng)字體文件。

　　在系統(tǒng)啟動(dòng)完成并開始加載非本地的字體文件時(shí)，就開啟用戶模式字體引擎。通過Winlogon控制的用戶模式字體引擎客戶端fontdrvhost.exe，利用NtGdiExtEscape同內(nèi)核進(jìn)行交互，為內(nèi)核的UMFD部分實(shí)現(xiàn)字體文件的解析、渲染工作，并給內(nèi)核模式返回需要的接口。

　　兩套接口并行、對(duì)外保持一致的數(shù)據(jù)交互，在不影響功能、消耗非常見情況下的較少性能的前提下，實(shí)現(xiàn)了字體數(shù)據(jù)解析和渲染的用戶模式+受限權(quán)限隔離。

　　即使字體解析和渲染過程中存在安全漏洞，也被限制在受限的用戶模式進(jìn)程中，需要進(jìn)一步利用其他安全漏洞才能最終完成攻擊，無法再直接獲得內(nèi)核的最高權(quán)限，使得這類型漏洞的風(fēng)險(xiǎn)大大降低，也使限制、發(fā)現(xiàn)這類漏洞攻擊更容易和更具備可能性。

　　小結(jié)

　　本文所介紹的非系統(tǒng)字體禁用和用戶模式字體驅(qū)動(dòng)機(jī)制，都是微軟在內(nèi)核模式字體引擎漏洞攻擊方面的緩和措施，分別通過安全策略、安全隔離的思想，提高內(nèi)核模式字體引擎漏洞的利用難度，降低了相關(guān)漏洞的安全風(fēng)險(xiǎn)。在特定的環(huán)境下，甚至可能完全杜絕遠(yuǎn)程字體漏洞的攻擊。這個(gè)安全措施稱得上是繼默認(rèn)開啟CFG后，Windows10又一可圈可點(diǎn)的新安全特性。

　　如同CFG在Windows10中默認(rèn)開啟后，逐步開放到Windows8.1 Update3的更新上，希望這個(gè)機(jī)制也能盡早磨練成熟，升級(jí)到后續(xù)的操作系統(tǒng)中，為更多用戶提供更好的安全保障。