溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
這篇文章主要介紹“CVE-2021-24093 Windows圖形組件遠程執行代碼漏洞的原因是什么”，在日常操作中，相信很多人在CVE-2021-24093 Windows圖形組件遠程執行代碼漏洞的原因是什么問題上存在疑惑，小編查閱了各式資料，整理出簡單好用的操作方法，希望對大家解答”CVE-2021-24093 Windows圖形組件遠程執行代碼漏洞的原因是什么”的疑惑有所幫助！接下來，請跟著小編一起來學習吧！
Windows圖形組件DWrite庫是用于高質量文本呈現的用戶模式動態庫，DWrite庫存在遠程代碼執行漏洞。目前已有POC，POC可以實現任意地址寫任意內容。
基于此我們做了分析，分析后得知字體庫文件中的”maxp”表內容存在錯誤數據時，DWrite庫使用此數據計算字體所需內存，導致分配內存過小，程序讀取字體庫中的數據寫入數組并越界寫入 到另外一個數據結構中，后續將結構中數據作為指針操作其中內容，寫入數據和指針都可控。通過分析補丁，補丁修補方案為：取出”maxp”表的另一字段再加4，比較之前畸形數據得到較大值，以此計算需要分配內存大小。
文章包含如下內容：
定位chrome引擎的渲染進程
使用條件記錄斷點動態調試分析
使用IDA補丁比較靜態分析
漏洞名稱：（Windows圖形組件遠程執行代碼漏洞）
漏洞編號：（CVE-2021-24093）
漏洞類型：（數組越界寫）
漏洞影響：（遠程代碼執行）
CVSS評分： 8.8
利用難度：不太容易利用
基礎權限：需要用戶訪問網頁
Microsoft DirectWrite是用于高質量文本呈現的現代Windows API。它的大部分代碼位于DWrite.dll用戶模式庫中。它用作各種廣泛使用的桌面程序（例如Windows上的chrome，Firefox和Edge）的字體光柵化程序。
使用chrome瀏覽器訪問Web頁面，渲染引擎進程異常，導致chorme頁面崩潰。
漏洞主要影響Win10的某些版本及Windows Server 2016、2019、2004、20H2等系統。
靶機環境: Windows 1909專業版 x64、chrome 86.0.4240.193 （64位）
poc.html放在本機，漏洞環境也在本機。
將POC文件與poc.ttf放在同一目錄下，使用chrome打開poc.html文件。
2.頁面打開，點擊確定按鈕加載ttf文件。
3.瀏覽器渲染引擎進程崩潰
4.定位進程崩潰地點
（1） 打開Html頁面時會啟動多個chrome進程，首先需要定位到哪個是渲染引擎進程。
（2）先關閉chrome瀏覽器(否則會影響定位結果)，使用火絨劍來定位渲染引擎進程，清空火絨劍記錄內容，開啟監控，設置動作過濾包括進程啟動和進程退出，點擊確定，然后開啟監控，如下：
（3）使用chrome打開poc.html，在彈出框上點擊確定，之后渲染引擎崩潰，關閉監控，查看監控到的內容，過濾監控內容，只需要包含chrome.exe的記錄，如下：
（4） 可以看到最后一個進程退出，進程ID為4228，渲染引擎崩潰，進程應該也會退出，假設最后一個進程是渲染引擎進程，它創建記錄是在從上往下數第七個，再試一次，重復(2-3)的過程，這次打開poc.html之后不要點擊確定按鈕，查看火絨劍記錄如下：
定位到第七個進程，進程ID為4948，使用Windbg x64附加此進程，(如果chrome瀏覽器切換到后臺，比如我點擊回到桌面，chrome會自動點擊確定按鈕，導致渲染進程退出，可以先打開windbg，不用切回桌面再打開windbg，或者使用雙屏幕也可以。)
附加成功之后，輸入g繼續運行，然后回到瀏覽器中，點擊確定按鈕，windbg斷下，如下：
可以看到引用一個錯誤的內存地址，發生異常，可知已經定位到正確的渲染進程。r8為0x0000414100004141，在網上下載的poc.ttf中有大量的41414141數據，筆者自己修改poc.ttf后與此處地址稍有不同，可見后續。
漏洞文件：DWrite.dll
漏洞函數：fsg_ExecuteGlyph
漏洞對象：TrueType字體中的”maxp”表
TrueType字體通常包含在單個TrueType字體文件中，其后綴為.TTF。TrueType中的所有數據都使用big-endian編碼，TTF文件中包含了字體的版本號和幾個表，每個表都有一個TableEntry結構項，TableEntry結構包含了資源標記、校驗和、偏移量和每個表的大小。下面是TrueType字體目錄的C語言定義:
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結構體， TableDirectory結構的最后一個字段是可變長度的TableEntry結構的數組，每個結構對應一個表。TrueType字體中的每個表都保存了不同的邏輯信息，其中”maxp”表的作用是描述字體中所需內存分配情況的匯總數據，”maxp”表的內容具體結構為：
typedef struct
{
Fixed version;// 0x00010000 for version 1.0
USHORT numGlyphs;
USHORT maxPoints;// 非復合字形中的最大點
USHORT maxContours;
USHORT maxCompositePoints;// 復合字形中的最大點
USHORT maxCompositeContours;
USHORT maxZones;
USHORT maxTwilightPoints;
USHORT maxStorage;
USHORT maxFunctionDefs;
USHORT maxInstructionDefs;
USHORT maxStackElements;
USHORT maxSizeOfInstructions;
USHORT maxComponentElements;// 任何復合字形在“頂級”處引用的最大組件數
USHORT maxComponentDepth;
}
poc.ttf中數據:
圖中箭頭1指向的數據為”maxp”表的TableEntry結構，Offset字段為00000158為箭頭2所指向的地方，是”maxp”表內容的具體結構，maxPoints字段值為0(距離箭頭2偏移0x6)，maxCompositePoints字段為3(距離箭頭2偏移0xA)。
AE標志符號的<gvar>表條目中的x和y增量在運行時會覆蓋到另一個數據結構，TTF中內容如下：
異常觸發時指令為add word ptr [r8+56h]，ax，ax為 0x9E9F(圖中1標記)，r8為0x00007A7B00007879(圖中2標記)的地址處，78 79 7A 7B都是TTF中的數據，補0是因為在異常指令之前對x數組和y數組調用了memset初始化內存空間。
poc.html中如下：
正常情況下，ttf文件中maxPoints字段值為0x168，maxCompositePoins字段值為0x2352，在poc.ttf文件中將”maxp”結構中maxPoints字段的值改為0，將maxCompositePoins值改為3，當加載并光柵化損壞的”maxp”表的數據時，會導致堆分配緩沖區過小，調用棧如下：
當復合字形?（AE，HTML實體＆＃198;，U + 00C6）被柵格化時，函數DWrite!fsg_ExecuteGlyph崩潰，調用棧如下：
fsg_ExecuteGlyph函數內部對堆塊內部的兩個整數數組(對應于x和y坐標)進行操作，使用0x148這個長度調用memset來初始化兩個數組，但是數組的長度小于0x148，會將跟在數組后面的一個指針置0。
如果字體是一個變量且指定了軸值，它還將調用TrueTypeRasterizer :: Implementation::ApplyOutlineVariation-> GlyphOutlineVariationInterpolator :: ApplyVariation會從TTF中獲取數據賦值給數組內的成員，但是數組較小，所以將數組后面的指針置為TTF中的數據。之后會向這個指針指向的地址中寫入數據導致異常。
漏洞庫版本如下：
崩潰函數fsg_ExecuteGlyph分析
在大的堆塊中，有兩塊內存分別用于x數組和y數組，調用memset初始化，之后調用call cs:off_7FFF41C70D10 ，函數內部會調用DWrite!TrueTypeRasterizer::Implementation::ApplyOutlineVariation給x數組和y數組賦值,addr1指向的內存沒有0x148字節那么大，所以會寫到其它的數據對象上，接下里會引用被覆蓋的數據作為指針去寫數據：
rsi+8中的數據被數組賦值時修改了，使用TTF中的數據覆蓋了[rsi+8]的數據，0x00007FFF41B341F6地址處調用的指令add [r8+56],ax，其中ax中的數據也是可以控制的。
計算內存大小的函數調用鏈為
TrueTypeRasterizer::Implementation::Initialize-> fs_NewSfnt ->fsg_WorkSpaceSetOffsets函數fsg_WorkSpaceSetOffsets內部計算需要申請的內存空間大小并將結果傳出到fs_NewSfnt中。
fs_NewSfnt獲取需要申請的內存大小，之后調用calloc申請內存。
可以看到圖中調用完成fs_NewSfnt后，在下面的循環中獲取v39內存塊中的內容作為申請內存的大小。
fs_NewSfnt函數內容如下：
v2為傳入的第二個參數a2，*((_DWORD *)v2 + 3)與fs_NewSfnt中取內存大小區域（*(_DWORD *)(v14 + 4i64 * j),j為3時）是一致的。
fsg_WorkSpaceSetOffsets函數補丁前后有修改。
查看補丁前fsg_WorkSpaceSetOffsets函數偽C代碼如下：
其中參數v3指向”maxp”表具體內容
可以看到圖中從maxCompositePoints和maxPoints字段中取較大值，并且與常量1比較取較大值，得到值為3，之后加8，得到0xb，作為第一個參數傳入fsg_GetOutlineSizeAndOffsets中，這個函數看名稱應該是獲取輪廓的大小和偏移值。
補丁后fsg_WorkSpaceSetOffsets函數偽C代碼有點問題，所以下面貼出匯編代碼如下：
打過補丁后，程序是先從maxCompositePoints和maxPoints字段中取較大值，得到3，再與1比較得較大值仍然為3，3+8得到0xb，再取出maxp表中maxComponentElements字段，POC中此值為0x0062，相對”maxp”表具體內容偏移為0x1C
0x62+4=0x66，比較0x66與0xb得到較大值作為第一個參數傳入fsg_GetOutlineSizeAndOffsets函數中。
函數fsg_GetOutlineSizeAndOffsets沒有變化，只是因為傳入的第一個參數不同，所以最終計算出的結果也不同。
fsg_ExecuteGlyph函數對堆塊內部的兩個整數數組，對應于x坐標和y坐標進行操作，實際上數組的較小，fsg_ExecuteGlyph函數先調用了兩次memset將數組清零，如果字體是一個變量且指定了軸值，還會調用TrueTypeRasterizer::Implementation::ApplyOutlineVariation->GlyphOutlineVariationInterpolator::ApplyVariation將字體中的數據賦值到坐標數組，這樣就會破壞到后續的結構成員。
計算所需內存的過程可以通過條件斷點的方式來調試，附加到調試器后，可以設置如下斷點命令，
bp DWrite!TrueTypeRasterizer::Implementation::Initialize "r $t0=$t0+1; .printf \"Initialize times:%d\n\",@$t0;.echo;gc"
可以看到第13次調用TrueTypeRasterizer::Implementation::Initialize函數之后就會進入崩潰。
重新啟動，下斷點：
bp DWrite!TrueTypeRasterizer::Implementation::Initialize "r $t0=$t0+1; .printf \"Initialize times:%d\n\",@$t0;.echo;.if(@$t0 == 0x0D){}.else{gc}"
運行可以看到：
在調用fs_NewSfnt之前下斷點，查看傳入參數內容：
單步步過，再次查看內存，可以看到需要申請的內存大小為0x6fa4。
繼續往下運行：
可以看到申請的內存地址為0x00000196bc484b60。
在崩潰函數中下斷點，運行：
堆塊起始地址為上面的申請的0x00000196bc484b60，調用memset使用的大小為0x148，上面是內存塊1，addr1為0x00000196bc4850fc
查看堆塊大小以及addr1相對堆塊起始地址的偏移大小如下：
最終調用fsg_ExecuteGlyph+0x772處的指令add [r8+56h], ax時，a8來源于[rsi+8]
查看rsi+8相對于堆塊的偏移
rsi+8相對于堆塊起始地址偏移0x6c8，而addr1相對于堆塊起始地址偏移0x59c，0x59c+0x148=0x6E4>0x6C8，所以操作addr1中的數據時會覆蓋rsi+8處的數據，從圖上可以看到，調用memset后rsi+8中的數據初始化為0。
調用ApplyOutlineVariation函數之后，rsi+8處數據被修改為ttf文件中的數據。（重新啟動，內存地址與上面不一樣）
繼續運行，如下：
可以看到ax為0x9e9f，r8為0x00007a7b00007879，這兩個數據都在poc.ttf文件中的數據，所以這個指針數據可控(where)，要寫入的內容(what)也可控。
打過補丁之后查看DWrite!fsg_ExecuteGlyph函數沒有變化，調試發現整個堆塊的大小變得更大了，x數組和y數組的大小還是0x148字節，ESI對象距離堆塊起始地址的距離變大，所以在x數組和y數組的賦值過程中沒有覆蓋到ESI對象,如下：
可以看到堆塊大小為0x7d24，之前為0x6fa4。
addr1結束地址為0x0000015fd070427c<0x0000015fd0704868，所以數組使用0x148的大小不會覆蓋到后面的數據。
TTF文件的”maxp”表描述字體中所需內存分配情況的匯總數據，DWrite庫沒有校驗數據，在ttf中寫入畸形數據時，程序申請內存過小，導致溢出到其它的數據結構，實現了任意地址寫任意數據。補丁在計算所需內存時讀取ttf中另一個值+4，與之前畸形數據比較得較大值，申請足夠的內存。
到此，關于“CVE-2021-24093 Windows圖形組件遠程執行代碼漏洞的原因是什么”的學習就結束了，希望能夠解決大家的疑惑。理論與實踐的搭配能更好的幫助大家學習，快去試試吧！若想繼續學習更多相關知識，請繼續關注億速云網站，小編會繼續努力為大家帶來更多實用的文章！
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
