CVE-2017-11882分析總結

注：這篇隨筆記錄了CVE-2017-11882漏洞分析的整個過程，並介紹了相關調試軟件的使用

漏洞信息

CVE-2017-11882屬於緩沖區溢出類型漏洞，產生漏洞原因於EQNEDT32.EXE（微軟office自帶公式編輯器）進程在讀入包含MathType的ole數據時，在拷貝公式字體名稱（Font Name數據）時沒有對名稱長度進行校驗，導致緩沖區溢出。通過覆蓋函數的返回地址，可執行任意代碼。

漏洞復現

1. 環境配置

操作系統：Window 7 專業版（64 位）
office軟件：office 2003 sp3 完整版 http://www.xz7.com/downinfo/36948.html
poc：https://github.com/embedi/CVE-2017-11882
注意：office 必須是帶有公式編輯功能的，所以不能下載精簡版的office。其次，在安裝時必須選擇完全安裝，防止漏掉公式編輯功能。

2. 流程

在配置好環境的虛擬機上，打開poc，雙機exploit.rtf文件，能正常已啟動office軟件並彈出calc.exe 則成功觸發漏洞。

漏洞分析

1. 定位漏洞

分析漏洞的第一步自然是定位漏洞。

第一步:

找到漏洞發生在哪個模塊，但是第一步就遇到了問題。我用processhacker分析進程狀態，可以看到WINWOED.EXE 和 calc.exe被創建出來，WINWOED.EXE由explore創建，這個沒問題，因為我是雙擊的文件打開的。calc.exe由 cmd.exe創建，也沒問題，說明poc應該是拉起cmd的同時命令行傳參，打開calc的。看不到cmd的父進程，這個不合理，至少有一個進程之類東西負責拉起cmd。這里沒顯示，我感覺有可能是這個父進程把自己隱藏了，或者跑路了。
接着我選擇用pchunter來檢測進程，因為pchunter的檢測能力較強。從pchunter中能找到所有進程對應的父進程，但是這個關鍵的cmd的父進程id：1872卻找不到對應的進程。雖然找到了這個關鍵進程的id，但是還是不知道它是誰。推測大概率是這個1872進程已經結束了，它的生命周期非常短。
花了很長時間，找到了解決方法，使用process monitor。process monitor雖然沒有process hack那種動態變色方便觀察的功能，但是它有個樹形控件，看到所有進程之間的關系。但是依舊是遇到了一些困難，官網下載的process monitor 無法在我這個win7虛擬機上運行，顯示錯誤：無法加載設備驅動。一番百度之下，找到一個解決方案，給win7打上某個補丁就可以。但是我覺得這個方案不行，因為我是復現poc，要是隨便打補丁的話，就沒有意義了。
但是我記得幾年前我用過這個軟件，是沒問題的，所以我去下載了一個老版本：2.5，於是可以正常運行。
點擊這個樹形控件之后，成功找到了1872這個進程：EQNEDT32.exe，並根據路徑找到了文件地址。從這個監控可以看出，EQNEDT32進程已經變灰了，說明它已經結束了，存在的時間很短。

第二步：

定位是這個EQNEDT32哪個函數有問題。原文是用的OD分析的，我使用的是windbg。因為這個EQNEDT32是自動啟動並且很快結束了，所以必須要能在它運行的第一時間就掛上調試器。這里有兩個解決辦法，第一個是利用windbg的小工具gflag。它和windbg在同一層目錄。
我們調試的是應用層軟件，所以選擇image file，然后填寫名字和調試器路徑即可。
還有一個方法是直接寫注冊表，方法一實質也是寫注冊表
這樣子，只要EQNEDT32進程被創建就會立即被windbg掛住。
根據poc可以彈出calc，可以猜測程序中調用了WinExec，CreateProcess之類的api，

注：這上面的第一個斷點是錯誤示范，我第一次下斷點，輸錯了模塊名，導致斷點下不上，一度以為是符號的問題，不能在這些系統api上下斷點。
直接g命令，或者f5 運行，第一處斷點就找到了WinExec，
查看函數棧，可以看到函數地址，以及參數。
其中 00430c18是函數返回地址，0018354是函數參數，查看0018354這個地址里的內容，可以看見cmd.exe /c calc.exe 字樣，說明找到了poc觸發位置。
再次查看函數棧，發現調用者返回地址是004218。查看這個地址的匯編。
找到EqnEdt32.exe中存在漏洞的函數，至此定位到漏洞函數。

第三步：

分析漏洞原因。在ida中找這個函數，G + 004218df
找到這個函數sub_4115A7，開始靜態分析可能存在漏洞的地方。
這個函數很短沒什么問題，查看sub_41160F
在sub_41160F可以發現有一個字符串拷貝函數未作長度檢驗，也沒有使用安全函數。這個地方就是漏洞所在。

2. 分析漏洞利用

ida分析發現實際存在字符串拷貝溢出的函數是sub_441160F，其地址為004115d3
再次運行windbg，在004115d3處下斷點
進入這個函數，單步到字符串拷貝的地方
分析棧幀發現，目前都很正常，函數返回地址被正確保存。rep movs dword ptr es:[edi],dword ptr [esi] 是字符串拷貝的關鍵步驟，它將esi指向的地址里的內存拷貝給edi指向的地址，先5查看兩者內存，到這步還是正常的。
但是參數的長度超過了申請的變量大小，執行該語句之后，覆蓋了原始返回地址
新的地址00430c12 就是 exe中原有的winexec函數。
可見，這個poc沒有在shellcode中執行跳轉指令，而是直接找了現有的一個API函數，在正常流程return的時候，覆蓋函數返回地址，插入了惡意代碼。