CVE-2012-0158基於exp分析

CVE-2012-0158這個洞我之前分析過，漏洞戰爭這本書裡也寫過，但是都是用poc分析的，我這次找了一個彈計算器的exp來分析，感覺用poc和用exp還是不一樣的，從exp分析要比從poc分析更復雜一些，或者說是要使用一些獨特的小技巧。順帶補齊漏洞利用的內容，上次沒有寫這個，看了一下漏洞分析這本書也沒有寫怎麼利用的這個漏洞。

0x0.分析漏洞

0x2.漏洞本質成因

0x3.漏洞利用

0x0.分析漏洞

首先是用windbg掛載word2003程式，F5繼續執行之後載入exp檔案,會發現中斷在瞭如圖所示的地方。

可以由圖看出來這是程式退出了，由此推測是shellcode執行完成並且安全順利的退出了程式。我們要做的就是定位shellcode在記憶體中的位置。kp一下，如圖。可以看到是剛剛呼叫了ExitProcess函式。

透過對ExitProcess函式下斷就可以順藤摸瓜找到shellcode的位置，如圖我們可以看到ExitProcess的呼叫位置是0x12165C，這個地址明顯是在棧上的。

我們來看下0x12165C這個地址到底是有什麼東西，如圖可以看到確實是shellcode。

然後就是最重要的問題了，我們知道棧溢位是函式向棧上寫入資料導致的。我們現在已經知道了棧上的寫入位置了，那麼怎麼找出是在哪個函式中進行寫入的呢？這裡就是一個技巧了，也是從仙果版主那裡學到的。

方法是：對這塊棧下寫入記錄斷點，根據斷點輸出情況來分析。

但是這個斷點會影響效率，所以我們儘可能晚的去下記錄斷點。我們在準備開啟檔案時Ctrl+Break丟擲一個斷點。然後下斷ba w 4 0x12165C "r eip;gc"，輸出如圖。

可以看到了，最後一個非棧上eip既是漏洞的觸發點。如果對這個地方下斷的話可以看到0x275c87cb這個地方的是執行過多次的，我們反覆除錯可以找到最後觸發漏洞的那一次，也可以對ecx即複製的大小下條件斷點進行輸出來看一下什麼情況。

如圖所示我使用了 ba e 1 MSCOMCTL!DllGetClassObject+0x41a84 "r ecx;gc"來下條件記錄斷點，輸出可以看到有一個超大的ecx=0x8282而我們知道ecx就是複製的次數也就是複製的位元組數，這裡我們就找到了是第4次呼叫到memcpy時發生了溢位。

在第四次呼叫時斷下來，看一下前面。我們可以看到以下一些語句

1 275c878a 8b7d10      mov    edi,dword ptr [ebp+10h]
2 275c87c1 8bcf        mov    ecx,edi
3 275c87c8 c1e902      shr    ecx,2
4 275c87cb  f3a5       rep movs dword ptr es:[edi],dword ptr [esi]

可以看出所謂的複製的位元組數其實是來自上層傳遞過來的引數3。來kv看一下，的確如此。

我們在IDA裡看一下到底是怎麼導致的漏洞

可以看到引數都是從上面傳過來的，0x8282這麼大的導致溢位的值也是上層出現的問題，我們繼續往上跟蹤。我們知道棧溢位是屬於一個函式的棧，我們的目的就是找出是那個函式的區域性變數緩衝區被溢位了，所以我們要明確向上跟蹤的目標，就是找出是某個函式的區域性變數我們的目的就達到了。

 根據00121458 275e701a 06b5ce6c 07a70810 00000000 MSCOMCTL!DllGetClassObject+0x41cc6這個棧回溯來看，我們繼續跟到了這個函式位置。如下圖

根據上圖我們明顯的看到了漏洞的造成，目的地址是棧中的一個8位元組的區域性緩衝區，但是在複製的時候判斷複製尺寸的大小使用cmp [ebp+dwBytes],8 jb loc_275d3085時卻是大於8時跳轉到複製路徑（注意那根紅色的線），所以就造成了明顯的溢位。

至此，漏洞分析完畢。

0x2.漏洞本質成因

如果是根據網上的資料來看的話，樣本的分析應該很簡單，只是一個OLE物件而已。但是我手裡只有一個經過加密的exp（而且還是excel的）。這就給分析工作增大了難度