CVE-2021-24093 Windows圖形組件遠(yuǎn)程執(zhí)行代碼漏洞的原因是什么

這篇文章主要介紹“CVE-2021-24093 Windows圖形組件遠(yuǎn)程執(zhí)行代碼漏洞的原因是什么”，在日常操作中，相信很多人在CVE-2021-24093 Windows圖形組件遠(yuǎn)程執(zhí)行代碼漏洞的原因是什么問題上存在疑惑，小編查閱了各式資料，整理出簡(jiǎn)單好用的操作方法，希望對(duì)大家解答”CVE-2021-24093 Windows圖形組件遠(yuǎn)程執(zhí)行代碼漏洞的原因是什么”的疑惑有所幫助！接下來，請(qǐng)跟著小編一起來學(xué)習(xí)吧！

一、      前言

Windows圖形組件DWrite庫(kù)是用于高質(zhì)量文本呈現(xiàn)的用戶模式動(dòng)態(tài)庫(kù)，DWrite庫(kù)存在遠(yuǎn)程代碼執(zhí)行漏洞。目前已有POC，POC可以實(shí)現(xiàn)任意地址寫任意內(nèi)容。

基于此我們做了分析，分析后得知字體庫(kù)文件中的”maxp”表內(nèi)容存在錯(cuò)誤數(shù)據(jù)時(shí)，DWrite庫(kù)使用此數(shù)據(jù)計(jì)算字體所需內(nèi)存，導(dǎo)致分配內(nèi)存過小，程序讀取字體庫(kù)中的數(shù)據(jù)寫入數(shù)組并越界寫入 到另外一個(gè)數(shù)據(jù)結(jié)構(gòu)中，后續(xù)將結(jié)構(gòu)中數(shù)據(jù)作為指針操作其中內(nèi)容，寫入數(shù)據(jù)和指針都可控。通過分析補(bǔ)丁，補(bǔ)丁修補(bǔ)方案為：取出”maxp”表的另一字段再加4，比較之前畸形數(shù)據(jù)得到較大值，以此計(jì)算需要分配內(nèi)存大小。

文章包含如下內(nèi)容：

• 定位chrome引擎的渲染進(jìn)程

• 使用條件記錄斷點(diǎn)動(dòng)態(tài)調(diào)試分析

• 使用IDA補(bǔ)丁比較靜態(tài)分析

二、      漏洞信息

1. 漏洞簡(jiǎn)述

• 漏洞名稱：（Windows圖形組件遠(yuǎn)程執(zhí)行代碼漏洞）

• 漏洞編號(hào)：（CVE-2021-24093）

• 漏洞類型：（數(shù)組越界寫）

• 漏洞影響：（遠(yuǎn)程代碼執(zhí)行）

• CVSS評(píng)分： 8.8

• 利用難度：不太容易利用

• 基礎(chǔ)權(quán)限：需要用戶訪問網(wǎng)頁(yè)

2. 組件概述

Microsoft DirectWrite是用于高質(zhì)量文本呈現(xiàn)的現(xiàn)代Windows API。它的大部分代碼位于DWrite.dll用戶模式庫(kù)中。它用作各種廣泛使用的桌面程序（例如Windows上的chrome，F(xiàn)irefox和Edge）的字體光柵化程序。

3. 漏洞利用

使用chrome瀏覽器訪問Web頁(yè)面，渲染引擎進(jìn)程異常，導(dǎo)致chorme頁(yè)面崩潰。

4. 漏洞影響

漏洞主要影響Win10的某些版本及Windows Server 2016、2019、2004、20H2等系統(tǒng)。

三、漏洞復(fù)現(xiàn)

1. 環(huán)境搭建

• 靶機(jī)環(huán)境: Windows 1909專業(yè)版 x64、chrome 86.0.4240.193 （64位）

poc.html放在本機(jī)，漏洞環(huán)境也在本機(jī)。

2. 復(fù)現(xiàn)過程

1. 將POC文件與poc.ttf放在同一目錄下，使用chrome打開poc.html文件。

2.頁(yè)面打開，點(diǎn)擊確定按鈕加載ttf文件。

3.瀏覽器渲染引擎進(jìn)程崩潰

4.定位進(jìn)程崩潰地點(diǎn)

（1） 打開Html頁(yè)面時(shí)會(huì)啟動(dòng)多個(gè)chrome進(jìn)程，首先需要定位到哪個(gè)是渲染引擎進(jìn)程。

（2）先關(guān)閉chrome瀏覽器(否則會(huì)影響定位結(jié)果)，使用火絨劍來定位渲染引擎進(jìn)程，清空火絨劍記錄內(nèi)容，開啟監(jiān)控，設(shè)置動(dòng)作過濾包括進(jìn)程啟動(dòng)和進(jìn)程退出，點(diǎn)擊確定，然后開啟監(jiān)控，如下：

（3）使用chrome打開poc.html，在彈出框上點(diǎn)擊確定，之后渲染引擎崩潰，關(guān)閉監(jiān)控，查看監(jiān)控到的內(nèi)容，過濾監(jiān)控內(nèi)容，只需要包含chrome.exe的記錄，如下：

（4） 可以看到最后一個(gè)進(jìn)程退出，進(jìn)程ID為4228，渲染引擎崩潰，進(jìn)程應(yīng)該也會(huì)退出，假設(shè)最后一個(gè)進(jìn)程是渲染引擎進(jìn)程，它創(chuàng)建記錄是在從上往下數(shù)第七個(gè)，再試一次，重復(fù)(2-3)的過程，這次打開poc.html之后不要點(diǎn)擊確定按鈕，查看火絨劍記錄如下：

定位到第七個(gè)進(jìn)程，進(jìn)程ID為4948，使用Windbg x64附加此進(jìn)程，(如果chrome瀏覽器切換到后臺(tái)，比如我點(diǎn)擊回到桌面，chrome會(huì)自動(dòng)點(diǎn)擊確定按鈕，導(dǎo)致渲染進(jìn)程退出，可以先打開windbg，不用切回桌面再打開windbg，或者使用雙屏幕也可以。)

附加成功之后，輸入g繼續(xù)運(yùn)行，然后回到瀏覽器中，點(diǎn)擊確定按鈕，windbg斷下，如下：

可以看到引用一個(gè)錯(cuò)誤的內(nèi)存地址，發(fā)生異常，可知已經(jīng)定位到正確的渲染進(jìn)程。r8為0x0000414100004141，在網(wǎng)上下載的poc.ttf中有大量的41414141數(shù)據(jù)，筆者自己修改poc.ttf后與此處地址稍有不同，可見后續(xù)。

四、漏洞分析

1. 基本信息

• 漏洞文件：DWrite.dll

• 漏洞函數(shù)：fsg_ExecuteGlyph

• 漏洞對(duì)象：TrueType字體中的”maxp”表

2. 背景知識(shí)

TrueType字體通常包含在單個(gè)TrueType字體文件中，其后綴為.TTF。TrueType中的所有數(shù)據(jù)都使用big-endian編碼，TTF文件中包含了字體的版本號(hào)和幾個(gè)表，每個(gè)表都有一個(gè)TableEntry結(jié)構(gòu)項(xiàng)，TableEntry結(jié)構(gòu)包含了資源標(biāo)記、校驗(yàn)和、偏移量和每個(gè)表的大小。下面是TrueType字體目錄的C語(yǔ)言定義:

typedef sturct

{

char   tag[4];

ULONG   checkSum;

ULONG   offset;

ULONG   length;

}TableEntry;

typedef struct

{

Fixed   sfntversion;   //0x00010000   for   version   1.0

USHORT   numTables;

USHORT   searchRange;

USHORT   entrySelector;

USHORT   rangeShift;

TableEntry   entries[1];//variable   number   of   TableEntry

}TableDirectory;

文件開頭為TableDirectory結(jié)構(gòu)體， TableDirectory結(jié)構(gòu)的最后一個(gè)字段是可變長(zhǎng)度的TableEntry結(jié)構(gòu)的數(shù)組，每個(gè)結(jié)構(gòu)對(duì)應(yīng)一個(gè)表。TrueType字體中的每個(gè)表都保存了不同的邏輯信息，其中”maxp”表的作用是描述字體中所需內(nèi)存分配情況的匯總數(shù)據(jù)，”maxp”表的內(nèi)容具體結(jié)構(gòu)為：

typedef struct

{

Fixed version;// 0x00010000 for version 1.0

USHORT numGlyphs;

USHORT maxPoints;// 非復(fù)合字形中的最大點(diǎn)

USHORT maxContours;

USHORT maxCompositePoints;// 復(fù)合字形中的最大點(diǎn)

USHORT maxCompositeContours;

USHORT maxZones;

USHORT maxTwilightPoints;

USHORT maxStorage;

USHORT maxFunctionDefs;

USHORT maxInstructionDefs;

USHORT maxStackElements;

USHORT maxSizeOfInstructions;

USHORT maxComponentElements;// 任何復(fù)合字形在“頂級(jí)”處引用的最大組件數(shù)

USHORT maxComponentDepth;

}

3. 詳細(xì)分析

1. 基礎(chǔ)分析

poc.ttf中數(shù)據(jù):

圖中箭頭1指向的數(shù)據(jù)為”maxp”表的TableEntry結(jié)構(gòu)，Offset字段為00000158為箭頭2所指向的地方，是”maxp”表內(nèi)容的具體結(jié)構(gòu)，maxPoints字段值為0(距離箭頭2偏移0x6)，maxCompositePoints字段為3(距離箭頭2偏移0xA)。

AE標(biāo)志符號(hào)的<gvar>表?xiàng)l目中的x和y增量在運(yùn)行時(shí)會(huì)覆蓋到另一個(gè)數(shù)據(jù)結(jié)構(gòu)，TTF中內(nèi)容如下：

異常觸發(fā)時(shí)指令為add     word ptr [r8+56h]，ax，ax為 0x9E9F(圖中1標(biāo)記)，r8為0x00007A7B00007879(圖中2標(biāo)記)的地址處，78 79 7A 7B都是TTF中的數(shù)據(jù)，補(bǔ)0是因?yàn)樵诋惓Ｖ噶钪皩?duì)x數(shù)組和y數(shù)組調(diào)用了memset初始化內(nèi)存空間。

poc.html中如下：

正常情況下，ttf文件中maxPoints字段值為0x168，maxCompositePoins字段值為0x2352，在poc.ttf文件中將”maxp”結(jié)構(gòu)中maxPoints字段的值改為0，將maxCompositePoins值改為3，當(dāng)加載并光柵化損壞的”maxp”表的數(shù)據(jù)時(shí)，會(huì)導(dǎo)致堆分配緩沖區(qū)過小，調(diào)用棧如下：

當(dāng)復(fù)合字形?（AE，HTML實(shí)體＆＃198;，U + 00C6）被柵格化時(shí)，函數(shù)DWrite!fsg_ExecuteGlyph崩潰，調(diào)用棧如下：

fsg_ExecuteGlyph函數(shù)內(nèi)部對(duì)堆塊內(nèi)部的兩個(gè)整數(shù)數(shù)組(對(duì)應(yīng)于x和y坐標(biāo))進(jìn)行操作，使用0x148這個(gè)長(zhǎng)度調(diào)用memset來初始化兩個(gè)數(shù)組，但是數(shù)組的長(zhǎng)度小于0x148，會(huì)將跟在數(shù)組后面的一個(gè)指針置0。

如果字體是一個(gè)變量且指定了軸值，它還將調(diào)用TrueTypeRasterizer :: Implementation::ApplyOutlineVariation-> GlyphOutlineVariationInterpolator :: ApplyVariation會(huì)從TTF中獲取數(shù)據(jù)賦值給數(shù)組內(nèi)的成員，但是數(shù)組較小，所以將數(shù)組后面的指針置為TTF中的數(shù)據(jù)。之后會(huì)向這個(gè)指針指向的地址中寫入數(shù)據(jù)導(dǎo)致異常。

漏洞庫(kù)版本如下：

2. 靜態(tài)分析

崩潰函數(shù)fsg_ExecuteGlyph分析

在大的堆塊中，有兩塊內(nèi)存分別用于x數(shù)組和y數(shù)組，調(diào)用memset初始化，之后調(diào)用call    cs:off_7FFF41C70D10 ，函數(shù)內(nèi)部會(huì)調(diào)用DWrite!TrueTypeRasterizer::Implementation::ApplyOutlineVariation給x數(shù)組和y數(shù)組賦值,addr1指向的內(nèi)存沒有0x148字節(jié)那么大，所以會(huì)寫到其它的數(shù)據(jù)對(duì)象上，接下里會(huì)引用被覆蓋的數(shù)據(jù)作為指針去寫數(shù)據(jù)：

rsi+8中的數(shù)據(jù)被數(shù)組賦值時(shí)修改了，使用TTF中的數(shù)據(jù)覆蓋了[rsi+8]的數(shù)據(jù)，0x00007FFF41B341F6地址處調(diào)用的指令add [r8+56],ax，其中ax中的數(shù)據(jù)也是可以控制的。

1.      函數(shù)調(diào)用鏈

計(jì)算內(nèi)存大小的函數(shù)調(diào)用鏈為

TrueTypeRasterizer::Implementation::Initialize-> fs_NewSfnt ->fsg_WorkSpaceSetOffsets函數(shù)fsg_WorkSpaceSetOffsets內(nèi)部計(jì)算需要申請(qǐng)的內(nèi)存空間大小并將結(jié)果傳出到fs_NewSfnt中。

fs_NewSfnt獲取需要申請(qǐng)的內(nèi)存大小，之后調(diào)用calloc申請(qǐng)內(nèi)存。

可以看到圖中調(diào)用完成fs_NewSfnt后，在下面的循環(huán)中獲取v39內(nèi)存塊中的內(nèi)容作為申請(qǐng)內(nèi)存的大小。

fs_NewSfnt函數(shù)內(nèi)容如下：

v2為傳入的第二個(gè)參數(shù)a2，*((_DWORD *)v2 + 3)與fs_NewSfnt中取內(nèi)存大小區(qū)域（*(_DWORD *)(v14 + 4i64 * j),j為3時(shí)）是一致的。

2.      補(bǔ)丁Diff

fsg_WorkSpaceSetOffsets函數(shù)補(bǔ)丁前后有修改。

查看補(bǔ)丁前fsg_WorkSpaceSetOffsets函數(shù)偽C代碼如下：

其中參數(shù)v3指向”maxp”表具體內(nèi)容

可以看到圖中從maxCompositePoints和maxPoints字段中取較大值，并且與常量1比較取較大值，得到值為3，之后加8，得到0xb，作為第一個(gè)參數(shù)傳入fsg_GetOutlineSizeAndOffsets中，這個(gè)函數(shù)看名稱應(yīng)該是獲取輪廓的大小和偏移值。

補(bǔ)丁后fsg_WorkSpaceSetOffsets函數(shù)偽C代碼有點(diǎn)問題，所以下面貼出匯編代碼如下：

打過補(bǔ)丁后，程序是先從maxCompositePoints和maxPoints字段中取較大值，得到3，再與1比較得較大值仍然為3，3+8得到0xb，再取出maxp表中maxComponentElements字段，POC中此值為0x0062，相對(duì)”maxp”表具體內(nèi)容偏移為0x1C

0x62+4=0x66，比較0x66與0xb得到較大值作為第一個(gè)參數(shù)傳入fsg_GetOutlineSizeAndOffsets函數(shù)中。

函數(shù)fsg_GetOutlineSizeAndOffsets沒有變化，只是因?yàn)閭魅氲牡谝粋€(gè)參數(shù)不同，所以最終計(jì)算出的結(jié)果也不同。

2. 漏洞函數(shù)分析

fsg_ExecuteGlyph函數(shù)對(duì)堆塊內(nèi)部的兩個(gè)整數(shù)數(shù)組，對(duì)應(yīng)于x坐標(biāo)和y坐標(biāo)進(jìn)行操作，實(shí)際上數(shù)組的較小，fsg_ExecuteGlyph函數(shù)先調(diào)用了兩次memset將數(shù)組清零，如果字體是一個(gè)變量且指定了軸值，還會(huì)調(diào)用TrueTypeRasterizer::Implementation::ApplyOutlineVariation->GlyphOutlineVariationInterpolator::ApplyVariation將字體中的數(shù)據(jù)賦值到坐標(biāo)數(shù)組，這樣就會(huì)破壞到后續(xù)的結(jié)構(gòu)成員。

3.      動(dòng)態(tài)分析

計(jì)算所需內(nèi)存的過程可以通過條件斷點(diǎn)的方式來調(diào)試，附加到調(diào)試器后，可以設(shè)置如下斷點(diǎn)命令，

bp DWrite!TrueTypeRasterizer::Implementation::Initialize "r $t0=$t0+1; .printf \"Initialize times:%d\n\",@$t0;.echo;gc"

可以看到第13次調(diào)用TrueTypeRasterizer::Implementation::Initialize函數(shù)之后就會(huì)進(jìn)入崩潰。

重新啟動(dòng)，下斷點(diǎn)：

bp DWrite!TrueTypeRasterizer::Implementation::Initialize "r $t0=$t0+1; .printf \"Initialize times:%d\n\",@$t0;.echo;.if(@$t0 == 0x0D){}.else{gc}"

運(yùn)行可以看到：

在調(diào)用fs_NewSfnt之前下斷點(diǎn)，查看傳入?yún)?shù)內(nèi)容：

單步步過，再次查看內(nèi)存，可以看到需要申請(qǐng)的內(nèi)存大小為0x6fa4。

繼續(xù)往下運(yùn)行：

可以看到申請(qǐng)的內(nèi)存地址為0x00000196bc484b60。

在崩潰函數(shù)中下斷點(diǎn)，運(yùn)行：

堆塊起始地址為上面的申請(qǐng)的0x00000196bc484b60，調(diào)用memset使用的大小為0x148，上面是內(nèi)存塊1，addr1為0x00000196bc4850fc

查看堆塊大小以及addr1相對(duì)堆塊起始地址的偏移大小如下：

最終調(diào)用fsg_ExecuteGlyph+0x772處的指令add     [r8+56h], ax時(shí)，a8來源于[rsi+8]

查看rsi+8相對(duì)于堆塊的偏移

rsi+8相對(duì)于堆塊起始地址偏移0x6c8，而addr1相對(duì)于堆塊起始地址偏移0x59c，0x59c+0x148=0x6E4>0x6C8，所以操作addr1中的數(shù)據(jù)時(shí)會(huì)覆蓋rsi+8處的數(shù)據(jù)，從圖上可以看到，調(diào)用memset后rsi+8中的數(shù)據(jù)初始化為0。

調(diào)用ApplyOutlineVariation函數(shù)之后，rsi+8處數(shù)據(jù)被修改為ttf文件中的數(shù)據(jù)。（重新啟動(dòng)，內(nèi)存地址與上面不一樣）

繼續(xù)運(yùn)行，如下：

可以看到ax為0x9e9f，r8為0x00007a7b00007879，這兩個(gè)數(shù)據(jù)都在poc.ttf文件中的數(shù)據(jù)，所以這個(gè)指針數(shù)據(jù)可控(where)，要寫入的內(nèi)容(what)也可控。

打過補(bǔ)丁之后查看DWrite!fsg_ExecuteGlyph函數(shù)沒有變化，調(diào)試發(fā)現(xiàn)整個(gè)堆塊的大小變得更大了，x數(shù)組和y數(shù)組的大小還是0x148字節(jié)，ESI對(duì)象距離堆塊起始地址的距離變大，所以在x數(shù)組和y數(shù)組的賦值過程中沒有覆蓋到ESI對(duì)象,如下：

可以看到堆塊大小為0x7d24，之前為0x6fa4。

addr1結(jié)束地址為0x0000015fd070427c<0x0000015fd0704868，所以數(shù)組使用0x148的大小不會(huì)覆蓋到后面的數(shù)據(jù)。

五、總結(jié)

TTF文件的”maxp”表描述字體中所需內(nèi)存分配情況的匯總數(shù)據(jù)，DWrite庫(kù)沒有校驗(yàn)數(shù)據(jù)，在ttf中寫入畸形數(shù)據(jù)時(shí)，程序申請(qǐng)內(nèi)存過小，導(dǎo)致溢出到其它的數(shù)據(jù)結(jié)構(gòu)，實(shí)現(xiàn)了任意地址寫任意數(shù)據(jù)。補(bǔ)丁在計(jì)算所需內(nèi)存時(shí)讀取ttf中另一個(gè)值+4，與之前畸形數(shù)據(jù)比較得較大值，申請(qǐng)足夠的內(nèi)存。

到此，關(guān)于“CVE-2021-24093 Windows圖形組件遠(yuǎn)程執(zhí)行代碼漏洞的原因是什么”的學(xué)習(xí)就結(jié)束了，希望能夠解決大家的疑惑。理論與實(shí)踐的搭配能更好的幫助大家學(xué)習(xí)，快去試試吧！若想繼續(xù)學(xué)習(xí)更多相關(guān)知識(shí)，請(qǐng)繼續(xù)關(guān)注億速云網(wǎng)站，小編會(huì)繼續(xù)努力為大家?guī)砀鄬?shí)用的文章！