Office公式編輯器漏洞二代的原理分析、利用與防護方案是怎樣的

這篇文章將為大家詳細講解有關Office公式編輯器漏洞二代的原理分析、利用與防護方案是怎樣的，文章內容質量較高，因此小編分享給大家做個參考，希望大家閱讀完這篇文章后對相關知識有一定的了解。

在2018年1月9日的微軟例行更新中，微軟再一次對Office中的公式編輯器3.0產生的多個內存破壞漏洞進行了修補，并將這一系列漏洞歸類于編號CVE-2018-0802。

漏洞披露后，金睛安全研究團隊及時對漏洞相關安全事件進行了跟進。

漏洞影響版本：

Office 365

Microsoft Office 2000      

Microsoft Office 2003      

Microsoft Office 2007 Service Pack 3

Microsoft Office 2010 Service Pack 2

Microsoft Office 2013 Service Pack 1

Microsoft Office 2016

漏洞事件分析：

目前已知的漏洞觸發方式存在兩種。

其中一種由國內安全公司的研究員提出，利用了公式的FONT記錄解析漏洞，與之前的CVE-2017-11882漏洞較為接近。目前已經存在此種方式進行利用的在野樣本，由于新的利用方式在未打CVE-2017-11882補丁的機器上會造成崩潰，所以需要搭配之前的漏洞利用公式一同使用。

另一種由國外安全公司的研究員提出，使用了公式的MATRIX記錄(原報告中誤認為是SIZE記錄)解析漏洞來造成棧溢出。目前尚未發現利用此種方式的樣本。由于此種方式對ASLR機制的繞過需要暴力枚舉，會導致打開文檔的時間變得極長。

由于前者的報告已經非常詳細，且原理與CVE-2017-11882較為接近，本文將主要分析后者。

漏洞細節分析：

在CVE-2017-11882漏洞的一處修補(0x4164FA)中，修補代碼通過增加額外的參數(拷貝字符數)以及增加判斷語句、截斷語句的方式，修正了所產生的棧溢出。

修補前后的代碼如下圖所示：

圖 1 - 修補前后的代碼對比

但問題正出在這個修補方式上，由于利用類似讀入方式的代碼有多處，難免存在漏網之魚。通過對GetByte函數(0x416352)的XREF進行查看，可以查找到另一處可能產生越界拷貝的ReadData函數(0x443F6C)。

圖 2 - 存在漏洞的ReadData函數

實際拷貝的數據大小(real_size)的值經傳入的參數(size)計算后得出，但這個傳入的參數是在公式中的可控數據。因此將該值更改為較大的值，便會覆蓋掉棧上隨后的數據。

ReadData函數在0x443E34函數中被調用，繼續向上XREF發現僅有0x454F50地址處提到了該函數。向上查看可以發現0x454F30處是一個結構體，通過對這一部分進行逆向可以得到以下內容(參考http://rtf2latex2e.sourceforge.net/MTEF3.html)。

圖 3 - 對TAG進行解析的函數

而0x454F30處的結構體對應的是case 4，即MATRIX記錄。通過查閱可以發現MATRIX記錄的結構如下：

由于ProcessMatrixRecord(0x443E34)函數對rows和cols兩個變量的數值未進行檢驗，通過real_size = (2 * size + 9) / 8可以計算出實際復制的數據大小。

 通過實際的調試，可以得到棧上的內存布局如下：

 為rows指定0x1C(28)，即實際復制(2 * 28 + 9) / 8 = 8個字節，然后為cols指定一個較大的數值(本例中0x94，即復制38個字節)則會覆蓋掉棧上原本的內容。

假定基址為0x400000，首先先用一定的數據覆蓋到棧上，結果如下。

圖 4 - ret時各寄存器的狀態

圖 5 - ret時EAX寄存器所指向的地址

在執行ret語句時，EAX寄存器所指向的地址離樣本中可控的輸入數據相差0x32個字節。攻擊者可以通過構造ROP鏈，對EAX寄存器的值進行抬高，從而實現執行任意命令。Check Point所給出的思路如下：

圖 6 - ROP鏈構造思路

大體思路是通過將EAX寄存器的值兩次抬高(0x32 / 2 = 0x19)，然后使用其值作為WinExec的參數進行調用。

中間出現了一個地址值0x455B28。原因要從處理MATRIX記錄的函數ProcessMatrixRecord(0x443E34)說起。

圖 7 - 對MATRIX記錄進行解析的函數(ProcessMatrixRecord, 0x443E34)      

在上圖的第26行可以看到對sub_4428F0函數的調用，該調用有對a1(ebp+8)的讀寫操作(該數據是一個地址)，而在ReadData之后，我們所構造的數據已經覆寫了這塊內存，破壞了原有數據。所以，我們應該至少保證這四個字節的數據是一個可讀寫的地址。

由于微軟在CVE-2017-11882的修補程序中已經強制開啟了ASLR機制，所以使exploit奏效仍需繞過此機制。這種方法利用了Word的一個特性：當公式編輯器產生異常時，Word會接管異常并不給出任何提示信息。而EQNEDT32.exe是一個32位進程，ASLR空間對應的基址尚且處于可以枚舉的范圍內——通過構造大量的公式，使用不同的基址構造ROP鏈即可繞過ASLR機制。

但在Check Point的POC演示視頻中可以發現，Word的加載窗口始終沒有消失，即Word一直在嘗試加載RTF文件，而計算器是在這個過程中被彈出的。筆者自己根據這種方法嘗試構造的POC有3MB的大小，觸發也需要數分鐘的時間，在實際的攻擊樣本中，利用此種溢出方式的樣本可能需要其他的方式繞過ASLR機制。

解決方案：

1、下載微軟最新補丁

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

(2)開啟Windows自動更新。微軟最新版本已經去掉了該模塊微軟將EQNEDT32.EXE從產品中刪除，并不再支持舊版本的公式格式。

2、在注冊表中取消該模塊的注冊

reg add “HKLM\SOFTWARE\Microsoft\Office\Common\COM Compatibility\{0002CE02-0000-0000-C000-000000000046}” /v “Compatibility Flags” /t REG_DWORD /d 0x400

對于在64位操作系統上的32位的Office，執行下列操作

reg add “HKLM\SOFTWARE\Wow6432Node\Microsoft\Office\Common\COM Compatibility\{0002CE02-0000-0000-C000-000000000046}” /v “Compatibility Flags” /t REG_DWORD /d 0x400

關于Office公式編輯器漏洞二代的原理分析、利用與防護方案是怎樣的就分享到這里了，希望以上內容可以對大家有一定的幫助，可以學到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到。