如何進行Office 0day漏洞CVE-2018-0802分析

本篇文章為大家展示了如何進行Office 0day漏洞CVE-2018-0802分析，內容簡明扼要并且容易理解，絕對能使你眼前一亮，通過這篇文章的詳細介紹希望你能有所收獲。

        2018年1月在微軟發布了新的安全補丁,其中修補了首個office 0day漏洞（CVE-2018-0802）, 該漏洞的技術原理類似于潛伏了17年的漏洞(CVE-2017-11882）, 是由于office公式編輯器組件EQNEDT32.EXE，對字體名的長度沒有進行長度檢驗, 導致攻擊者可以通過構造畸形的字體名,執行任意代碼。

漏洞介紹

威脅類型：任意代碼執行

威脅等級：高

漏洞名稱：CVE-2018-0802

受影響系統及應用版本：

Microsoft Office 2007  Service Pack3

Microsoft Office 2010  Service Pack2 (32-bit editions)

Microsoft Office 2010  Service Pack2 (64-bit editions)

Microsoft Office 2013  Service Pack1 (32-bit editions)

Microsoft Office 2013  Service Pack1 (64-bit editions)

Microsoft Office 2016  (32-bitedition)

Microsoft Office 2016  (64-bitedition)

補丁下載地址：

https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2018-0802

漏洞分析

        CVE-2018-0802為CVE-2017-11882的補丁繞過漏洞，類型為棧溢出，根本原因為微軟在CVE-2017-11882的補丁中沒有修復另一處拷貝字體FaceName時的棧溢出。本次漏洞在未打補丁的版本上只會造成crash，但在打補丁的版本上可以被完美利用。下面我們通過poc樣本來分析CVE-2018-0802漏洞。

圖1 漏洞程序版本信息

        與CVE-2017-11882一樣，本次漏洞的觸發數據位于所提取OLE對象的“Equation Native”流內。

圖2樣本構造的數據

Equation Native 數據結構

        據網上公開的資料，整個“EquationNative”的數據構成為：

        EquationNative StreamData = EQNOLEFILEHDR + MTEFData

        在漏洞利用文檔中，該結構如下所示：

圖3 EQNLEFILEHDR頭結構數據

圖4 MTEFData結構

圖5 MTEFData數據

        程序在初始化一個LOGFONT結構體時, 未對用戶輸入的字體名進行長度校驗,直接進行copy發生溢出, 漏洞函數:

圖6 漏洞觸發的函數

        LOGFONT 結構體指針由調用sub_421E39的sub_421774函數傳入, 結構體存在于sub_421774的函數棧上, 所以可以導致棧溢出,覆蓋返回地址,劫持執行流。

圖7 溢出函數

        分析過程中在sub_421774函數發現一處疑似遞歸的地方，sub_421774先是調用了漏洞函數sub_421E39去初始化一個LOGFONT結構體，然后調用相關API，傳入這個結構體，從系統獲取到一個字體名稱保存到Name。隨后，它將獲取到的Name和用戶提供的lpLogFont作對比，如果不一致則調用sub_4115A7函數, 這個函數間接調用CVE-2017-11882 的漏洞函數, 如果沒有安裝CVE-2017-11882這個補丁程序將在這里崩潰 ，之后會再根據a3指定的條件來繼續調用或者不調用自身，而a3為sub_421E39函數的第3個參數， 這里調用自身時傳入的第三個參數為0, 并且傳入的lpLogFont為從系統的獲取的Name所以不會發生二次溢出且不會繼續遞歸，所以函數可以正常返回。

圖8 函數調用流程

漏洞利用

        通過分析我們發現, 在sub_421774函數中發生溢出, 溢出原因是因為在初始化LOGFONT結構體的lfFaceName字段時發生溢出，通過漏洞分析中的圖2可以看出該結構體存在于函數棧距離返回地址(0xAC+0x4)的位置, 而lfFaceName的字段在LOGFONT結構體的偏移為0x1c, 如下圖, 所以要覆蓋返回地址需要填充(0xAC+0x4-0x1c)的數據。

圖9 LOGFONT結構體

        通過查看程序的保護屬性， 發現程序開啟了ALSR保護, 單并未開啟數據執行保護，值得一提的是,字體名的源緩沖區指針作為溢出函數的第一個參數傳入,并且函數使用stdcall調用協議,  也就是說當函數返回后, 字體名的源緩沖區的地址將保存在棧頂, 此時我們只要能執行一個ret指令就可以跳轉到字體名的源緩沖區的內存上執行。此時我們只需要繞過ALSR找到一個地址可靠的ret指令即可。有必要說一下ALSR并不是完全的地址隨機化， ALSR只會以0x10000為單位， 進行隨機， 假設我們返回地址為0xc014e2，那么如果在0xc00000到0xc0ffff的內存地址內找到一個ret指令，并且能做到只覆蓋返回地址的低地址的2個字節, 因為是字符串copy所以范圍縮小到0xc00000到0xc000ff。

        通過查找找到0xc00025這個地址

        根據之前的結論在覆蓋返回值之前有(0xAC+0x4-0x1c = 0x94)大小的空間, shellcode的大小必須小于等于0x94， 這也足夠了, shellcode布局:

圖9 shellcode布局

函數兩次返回,返回到字體名的源緩沖區執行代碼, 元緩沖區為我們構造的shellcode , shellcode 被執行, 漏洞被觸發

圖10 漏洞觸發后的場景

處理方案：

一、及時更新補丁

補丁下載地址：

https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2018-0802

二、通過注冊表禁用此模塊，可通過修改注冊表，禁用以下COM控件的方式進行緩解，其中XX.X為版本號

在運行中輸入：

reg add "HKLM\SOFTWARE\Microsoft\Office\XX.X\Common\COMCompatibility\{0002CE02-0000- 0000-C000-000000000046}" /v"Compatibility Flags" /t REG_DWORD /d 0x400

reg add"HKLM\SOFTWARE\Wow6432Node\Microsoft\Office\XX.X\Common\COMCompatibility\{0002CE02-0000-0000-C000-000000000046}" /v"Compatibility Flags" /t REG_DWORD /d 0x400

上述內容就是如何進行Office 0day漏洞CVE-2018-0802分析，你們學到知識或技能了嗎？如果還想學到更多技能或者豐富自己的知識儲備，歡迎關注億速云行業資訊頻道。