注： 這篇随筆記錄了CVE-2017-11882漏洞分析的整個過程，并介紹了相關調試軟體的使用
CVE-2017-11882屬于緩沖區溢出類型漏洞，産生漏洞原因于EQNEDT32.EXE（微軟office自帶公式編輯器）程序在讀入包含MathType的ole資料時，在拷貝公式字型名稱（Font Name資料）時沒有對名稱長度進行校驗，導緻緩沖區溢出。通過覆寫函數的傳回位址，可執行任意代碼。
作業系統：Window 7 專業版（64 位）
office軟體：office 2003 sp3 完整版 http://www.xz7.com/downinfo/36948.html
poc：https://github.com/embedi/CVE-2017-11882
注意：office 必須是帶有公式編輯功能的，是以不能下載下傳精簡版的office。其次，在安裝時必須選擇完全安裝，防止漏掉公式編輯功能。
在配置好環境的虛拟機上，打開poc，雙機exploit.rtf檔案，能正常已啟動office軟體并彈出calc.exe 則成功觸發漏洞。
分析漏洞的第一步自然是定位漏洞。
找到漏洞發生在哪個子產品，但是第一步就遇到了問題。我用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可以發現有一個字元串拷貝函數未作長度檢驗，也沒有使用安全函數。這個地方就是漏洞所在。
ida分析發現實際存在字元串拷貝溢出的函數是sub_441160F，其位址為004115d3
再次運作windbg，在004115d3處下斷點
進入這個函數，單步到字元串拷貝的地方
分析棧幀發現，目前都很正常，函數傳回位址被正确儲存。<code>rep movs dword ptr es:[edi],dword ptr [esi]</code>是字元串拷貝的關鍵步驟，它将esi指向的位址裡的記憶體拷貝給edi指向的位址，先5檢視兩者記憶體，到這步還是正常的。
但是參數的長度超過了申請的變量大小，執行該語句之後，覆寫了原始傳回位址
新的位址00430c12 就是 exe中原有的winexec函數。
可見，這個poc沒有在shellcode中執行跳轉指令，而是直接找了現有的一個API函數，在正常流程return的時候，覆寫函數傳回位址，插入了惡意代碼。
微軟已經對此漏洞做出了修複
下載下傳https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2017-11882 更新更新檔進行修補
在系統資料庫中取消該子產品的注冊