# CVE-2010-2883 粗略分析
###### tags: `exploitation`
這個其實是我在買了漏洞戰爭足足四年過後終於真的開始操作，主要是因為再不跟著操作就真的過期滿久了...

分析網路上很多，但自己做過比較安心，也容易知道問題會發生在哪，還可以沿路補足一些知識

## 工具
* windows xp (看過別人的分析 win7 也可以)
* ollydbg 110
* pdfstreamer
* adobe reader 9.3.4

樣本的部分可以上網找、從 malware 抓或是透過 meterpreter 生成 pdf

用法很簡單，從 rapid7 的[官網](https://www.metasploit.com/download)下載 framework ，安裝好後用法如下：

msf $ use exploit/windows/fileformat/adobe_cooltype_sing
msf $ set payload windows/exec
msf $ set cmd calc.exe
msf $ exploit

如此會生成樣本，可以拿來做利用

> 題外話，直接把樣本放到 host 的時候會因為 windows defender 偵測到 cve-2010-2883 而刪除，最好是關閉 defender 或是放到加密壓縮檔下
>

## 漏洞定位
書中明確指出是 CoolType.dll 某個 function 出現 stack based buffer overflow 問題，但我試著思考如果不知道這些資訊該怎麼定位漏洞，最簡單的方法就是透過公告找到漏洞發生在哪個 dll 然後補釘比對，但除了[這個網站](https://nvd.nist.gov/vuln/detail/CVE-2010-2883)之外其他基本上沒有對問題點著墨太多....

書中講明是 reader 解析字型的 SING 表時候發生問題導致 buffer overflow

而 SING 表的相關資訊 adobe 官網上好像沒有....，從書中的資訊應該是 SING table 有 table entry 結構 (header 的概念？)：

struct struct_SING
{
    char tag[4];
    ulong checksum;
    ulong offset;
    ulong length;
}

其中 offset 為 TableEntry 到真正 SING 結構的偏移，而 legnth 應該是 SING 結構大小

SING 結構如下：

struct SING
{
    ushort tableVersionMajor;
    ushort tableVersionMinor;
    ushort glyphletVersion;
    ushort embeddedInfo;
    ushort mainGID;
    short vertAdvance;
    short vertOrigin;
    char uniqueName[28];
    char METAMDS[16];
    char nameLength;
    char baseGlyphName[];
}

SING 結構在記憶體中的呈現：
> 這個找尋方式我有點取巧...，首先我知道在 0803DDAB 的時候會透過 SING + 0x10 進行 strcat ，回推發現在 0803DD8D 處對 eax 進行 dereference ，然後 eax 的來源在 0803DD82 說明是從 ebp - 0x24 來的
>

這次的漏洞利用就是透過 SING 結構在解析時未對 uniqueName 進行 strcat 做長度檢查，如果 uniqueName 沒有 null byte 終止，則會繼續複製一大堆字串到 local buffer 中

扯遠了，因為知道是 SING 解析出問題，而 SING 解析過程中會用到 "SING" 字串，所以可以透過字串 reference 找到出問題的 function: 0803DCF9
> 其實滿多 function 都用到這個字串，但加上後面有 strcat 這個條件的就剩一個了
>

我們可以再透過 pdfstreamer 看一下樣本結構

紅色部分是 SING 結構開頭，加上 0x10 後就是 uniqueName ，紅色區塊往上看可以看到 0x53 0x49 0x4e 0x47 ，這邊就是 SING 的 tableEntry 的部分

另外從 pdfstreamer 可以看到內嵌的 js code ，主要拿來做 heap spray 和布置 ROP gadget 用

## trace 漏洞
trace 漏洞前，建議直接用 reader 打開樣本確定到底可不可以成功 exploit ，以免浪費時間

如果直接用 ollydbg 打開 adobe reader 加載樣本會在中途就因為不知明原因瘋狂 exception 然後 terminated ，紀錄一下一個小技巧：
1. 先打開 reader -> open -> 滑鼠點在樣本上 (不要點兩下！)
2. 通常會報錯，不要理他， reader 不會關掉
3. ollydbg attach reader
4. 在 803ddab 的地方下斷點
5. F9 繼續執行
6. 回到 reader 打開樣本
7. 會遇到一堆 exception ，用 shift + f9 跳過即可

最後會停在 803ddab 上

接下來我慢慢跟，遇到 call 先 step over ，看會不會直接跳 calc.exe ，藉此判斷流程，根據我的跟蹤，應該是這樣的：

1. 803ddab `strcat overflow`
3. 803deaf `call 8016bde`
4. 8016c35 `call 801bb1c` 這邊的回傳值為 function pointer 的 address: `808b116`
5. 8016c56 `call 801bb21`
6. 801bb41 `call dword ptr [eax]` 對 *808b116 後的地址當 function pointer
7. 808b2e3 `mov eax, [edi + 3c]` edi + 0x3c 等於 0x12e6d0 ，在剛剛 overflow 的地址
8. 808b308 `call dword ptr [eax]` 進入 gadget

這邊有人說是覆蓋掉 seh ，但我個人認為不是，在尚未覆蓋前此區塊不是 seh chain ，原本的 function 應該是 80833ef 這個地址

我認為關鍵就在覆蓋到某個非常上層且放在 stack 的 function pointer ，而負責定位該地址的 edi 從頭到尾都沒變過，該 function pointer 不是 return address 也不是 seh 且執行過程基本上沒有 ret 回上層 stack frame ，故在 GS 的作用下應該還是可以利用的

## ROP
ROP 的部分簡單提一下，首先會用 add esp, 724 將 esp 設定的 overflowed-data 上設計好的 address ，隨即 pop rsp; ret 跳到 0x0c0c0c0c (利用 heap spray defeat aslr)

因為 0x0c0c0c0c 上不是可執行權限且沒有 ASLR 影響的 module 沒有更改現有的記憶體區塊的 API ，故使用以下 ROP chain 開了一個 RWE 權限的記憶體區塊：
1. CreateFileA
2. CreateFileMapping (設定為 RWX)
3. MapViewOfFile
4. memcpy

> 雖然說是 heap spray ，但透過 pop rsp; ret 可以非常精準的飛到 0x0c0c0c0c 上，故 exploit 直接在 0x0c0c0c0c 的位置放上 gadget address
>
## 總結
利用的方法不至於太陌生，但是對於漏洞的成因由於逆向能力不足，沒能搞清楚那個放在 stack 上的 function pointer 到底是哪來的感到遺憾...

不過我猜說不定 hacker 只是放滿 payload 後發現執行到後來 eip 會被改掉就拿來用也說不定 XD

##