來(lái)源：http://bbs.ichunqiu.com/thread-10108-1-1.html?from=ch
試想：某一天，你的基友給你了一個(gè)視頻文件蜈漓，號(hào)稱是陳老師拍的蒼老師的老師題材的最新電影.avi模叙，你滿心歡喜梁丘，在確定文件格式確實(shí)為avi格式后趋厉，愉快的脫下褲子準(zhǔn)備欣賞，打開(kāi)后卻發(fā)現(xiàn)什么也沒(méi)有汰现，而隨后你的基友就控制了你的電腦挂谍，把你辛辛苦苦珍藏了二十年的片源全部偷走了…….
今天我們分析的漏洞就是一個(gè)利用播放器解壓縮時(shí)處理不當(dāng)引起的遠(yuǎn)程執(zhí)行漏洞，這個(gè)漏洞并沒(méi)有大規(guī)模流行瞎饲，我們只是從技術(shù)角度解析漏洞成因口叙。
0x 00漏洞介紹
CVE 2010-2553漏洞，也稱為MicrosoftWindows Cinepak 編碼解碼器解壓縮漏洞嗅战，影響的操作系統(tǒng)版本有：Microsoft Windows XP SP2和SP3妄田，WindowsVista SP1和SP2，以及Windows 7驮捍。
漏洞原因在于Cinepak 編碼解碼器對(duì)媒體文件解壓縮時(shí)代碼控制不恰當(dāng)疟呐，可導(dǎo)致遠(yuǎn)程代碼執(zhí)行。如果用戶打開(kāi)特制的媒體文件东且，此漏洞可能允許執(zhí)行代碼启具。如果用戶使用管理用戶權(quán)限登錄，成功利用此漏洞的攻擊者便可完全控制受影響的系統(tǒng)珊泳。
漏洞利用wmplay.exe富纸，而wmplay.exe這個(gè)播放器在國(guó)內(nèi)很少有人使用囤踩，如果被攻擊者使用了第三方的視頻播放軟件旨椒，很難攻擊成功晓褪，這可能也是這一漏洞不被分析重視的一大原因。
0x 01漏洞觸發(fā)
本文分析環(huán)境如下：
操作系統(tǒng)
Xp sp3
iccvid.dll版本
1.10.0.12
通過(guò)在exploit-db網(wǎng)站上得到觸發(fā)漏洞的python腳本综慎，運(yùn)行python腳本后涣仿，生成可觸發(fā)漏洞的poc.avi，這就是我們分析的樣本文件示惊。(python腳本在文末的附件中)
通過(guò)公告可知好港，這個(gè)漏洞是個(gè)堆溢出漏洞，在分析堆漏洞時(shí)米罚，肯定是hpa + ust大法好铡俐。所以喂饥，首先我們要開(kāi)啟hpa、ust
使用windbg加載wmplay.exe，使用g命令售睹，運(yùn)行wmplay.exe
將poc.avi拖入wmplay中，windbg會(huì)觸發(fā)異常
通過(guò)崩潰信息猜測(cè)是堆中的內(nèi)存被破壞了程拭，我們看下edi的值建蹄，并看下這個(gè)值是不是堆地址
可以看到堆底地址為： 76ad000+600=76b3000，這個(gè)地址也正好是edi的地址动看，這正是由于我們使用glags.exe開(kāi)啟了頁(yè)堆檢查尊剔，堆管理器會(huì)在堆塊中增加不可訪問(wèn)的柵欄頁(yè)，當(dāng)溢出覆蓋到柵欄頁(yè)時(shí)就觸發(fā)了異常菱皆。
崩潰的指令為rep movs指令须误，我們看下此時(shí)movs的內(nèi)存大小保存在ecx，內(nèi)存大小為：
只能知道此時(shí)仇轻，是因?yàn)橄騟di中拷貝800大小字節(jié)的內(nèi)容時(shí)京痢，導(dǎo)致了堆溢出。
在rep movs這條指令的上一條指令下斷拯田，重新運(yùn)行
bu iccvid!CVDecompress+0x118:
第一次斷下后历造，查看edi,ecx的值：
走過(guò)rep movs指令后，此時(shí)并沒(méi)有崩潰船庇，這就說(shuō)明吭产，并不是一次rep movs就導(dǎo)致了堆溢出，而是通過(guò)多次運(yùn)行rep movs指令鸭轮，逐漸到到達(dá)堆尾臣淤，然后就溢出了。窃爷。邑蒋。姓蜂。
第二次斷下的，
第二次調(diào)用rep movs時(shí)医吊，還是沒(méi)有到達(dá)堆尾钱慢，還沒(méi)有溢出
第三次斷下時(shí)，
這時(shí)卿堂，可以看到束莫，edi=76b3000, 76b3000這個(gè)就是我們?cè)谝婚_(kāi)始崩潰的地方啊２菝琛＠缆獭！
在這里穗慕，可以看下esi的值
可以看到饿敲，現(xiàn)在用來(lái)覆蓋目標(biāo)地址的數(shù)據(jù)并不直接就是我們?cè)趐oc.avi中填充的數(shù)據(jù)，而是一些不知來(lái)自何處去向哪里的數(shù)據(jù)逛绵。這點(diǎn)就造成了我們對(duì)這個(gè)漏洞的利用不能向cve 2010 0158之類的漏洞利用一樣通過(guò)修改文件內(nèi)容即可實(shí)現(xiàn)覆蓋怀各。
0x 02 漏洞分析
定位函數(shù)
現(xiàn)在我們就定位到漏洞所在的函數(shù)，然后通過(guò)ida分析漏洞所在函數(shù)的功能暑脆。
在崩潰位置通過(guò)kb進(jìn)行椙。回溯來(lái)定位所在的函數(shù)
我們so easy的就把漏洞所在的函數(shù)找到了，這個(gè)函數(shù)就是iccvid!CVDecompress函數(shù)添吗。
使用IDA查看iccvid.dll文件沥曹，找到函數(shù)73b7cbee，發(fā)現(xiàn)ida并不能識(shí)別出函數(shù)為CVDecompress函數(shù)碟联，納尼妓美？？這一定是在逗我
這是因?yàn)镮DA沒(méi)有找到pdb文件鲤孵，但是我們windbg卻找到了pdb文件壶栋，我們將windbg的pdb文件拷貝出來(lái)，
在windbg中查看pdb文件路徑
使用ida file --- load file ---pdb file選擇pdb文件路徑普监，就可以在ida中看到函數(shù)名稱了贵试。
效果如圖
分析函數(shù)
在函數(shù)73B7CAD6頭下斷點(diǎn)后，重新加載程序凯正，斷下后毙玻，可以看到CVDecompress函數(shù)有七個(gè)參數(shù)：
還記得上面分析的rep movs指令嗎？調(diào)用它第三次后就會(huì)崩潰廊散，而第一次調(diào)用這條指令時(shí)的edi的值為076af000桑滩，這個(gè)076af000是什么鬼呢？來(lái)自于哪里呢允睹？
答案就是它是CVDecompress函數(shù)的從第一個(gè)參數(shù)运准，偏移1c的值(076ad000)加上2000后得到的……
CVDecompress函數(shù)的第三個(gè)參數(shù)68幌氮，代表了未解壓的數(shù)據(jù)長(zhǎng)度。
這個(gè)函數(shù)首先會(huì)對(duì)cinepak的壓縮格式結(jié)構(gòu)進(jìn)行判斷胁澳，隨后會(huì)按照cinepak壓縮格式解析結(jié)構(gòu)该互。
Cinepak壓縮格式的總體框架如下：
+-----------------------+
| Frame Header? ?? ?? ? |
+-----------------------+
| Strip 1 Header? ?? ???|
+-----------------------+
| Strip 1 Codebooks? ???|
+-----------------------+
| Strip 1 Frame Vectors |
+-----------------------+
| Strip 2 Header? ?? ???|
+-----------------------+
| Strip 2 Codebooks? ???|
+-----------------------+
| Strip 2 Frame Vectors |
+-----------------------+
| Strip 3 Header? ?? ???|
其中Frame Header的結(jié)構(gòu)如下：
7 6 5 4 3 2 1 0? ?? ???Field Name? ?? ?? ?? ?? ?? ???Type
+---------------+
0??|? ?? ?? ?? ? | |? ?? ? Flags? ?? ?? ?? ?? ?? ?? ?? ? Byte
+---------------+
1??|? ?? ?? ?? ?? ?|? ?? ? Length of CVID data? ?? ?? ???Unsigned
+-? ?? ?? ?? ? -+
2??|? ?? ?? ?? ?? ?|
+-? ?? ?? ?? ? -+
3??|? ?? ?? ?? ?? ?|
+---------------+
4??|? ?? ?? ?? ?? ?|? ?? ? Width of coded frame? ?? ?? ? Unsigned
+-? ?? ?? ?? ? -+
5??|? ?? ?? ?? ?? ?|
+---------------+
6??|? ?? ?? ?? ?? ?|? ?? ? Height of coded frame? ?? ?? ?Unsigned
+-? ?? ?? ?? ? -+
7??|? ?? ?? ?? ?? ?|
+---------------+
8??|? ?? ?? ?? ?? ?|? ?? ? Number of coded strips? ?? ???Unsigned
+-? ?? ?? ?? ? -+
9??|? ?? ?? ?? ?? ?|
+---------------+
函數(shù)首先判斷未解壓縮的數(shù)據(jù)長(zhǎng)度是不是小于20H大小
再判斷未解壓縮的數(shù)據(jù)長(zhǎng)度是不是小于FrameHeader中的數(shù)據(jù)長(zhǎng)度
比較Frame Header中的Number of coded strips是不是小于0
然后就會(huì)對(duì)每個(gè)strip進(jìn)行遍歷，以下都是在對(duì)每個(gè)strip的處理中
對(duì)未解壓的數(shù)據(jù)大小做比較
對(duì)編碼條數(shù)據(jù)大小做判斷
判斷編碼條ID為10還是11:
對(duì)strip header中的底部Y坐標(biāo)與頂部Y坐標(biāo)做差听哭，結(jié)果乘以一個(gè)數(shù)后存儲(chǔ)起來(lái)慢洋。
當(dāng)strip header中的編碼條ID為10時(shí)，會(huì)向堆中拷貝數(shù)據(jù)陆盘。
最后，會(huì)指向下一個(gè)stripHeader結(jié)構(gòu)败明。上面這些是對(duì)每個(gè)strip的處理
結(jié)合poc.avi的內(nèi)容隘马，與上面IDA中的結(jié)果
每次當(dāng)解析到chunkID為20時(shí)，此時(shí)妻顶，不會(huì)向堆里覆蓋內(nèi)容酸员，當(dāng)解析到chunkid=0x1100時(shí)，就會(huì)向堆數(shù)據(jù)中復(fù)制數(shù)據(jù)讳嘱。
因?yàn)閜oc.avi中有三處chunkid為11的數(shù)據(jù)塊幔嗦，因此向堆中復(fù)制了三次數(shù)據(jù)，而正是第三交復(fù)制時(shí)沥潭，使堆溢出而崩潰邀泉。
0x 04 漏洞利用
在metasploit 平臺(tái)中暫時(shí)沒(méi)有該漏洞利用的相關(guān)模塊，在互聯(lián)網(wǎng)搜索引擎中也暫未找到相關(guān)利用樣本钝鸽。本人感覺(jué)這個(gè)漏洞利用最大的難點(diǎn)在于汇恤，拷貝時(shí)觸發(fā)堆溢出時(shí)，拷貝的內(nèi)容很難通過(guò)文件內(nèi)容進(jìn)行控制拔恰，因而無(wú)法很好的控制EIP指針因谎，無(wú)法精準(zhǔn)的執(zhí)行payload。怎樣精準(zhǔn)的控制esi中的內(nèi)容颜懊，是我以后將在研究學(xué)習(xí)的內(nèi)容财岔。本文不再深入。
附件：鏈接：http://pan.baidu.com/s/1bLLx98密碼：mlbj
0x 05 參考資料
http://www.cvedetails.com/cve/CVE-2010-2553/
https://technet.microsoft.com/library/security/ms10-055
http://www.cnblogs.com/Ox9A82/p/5715673.html
http://cve.scap.org.cn/CVE-2010-2553.html
https://www.exploit-db.com/moaub-26-microsoft-cinepak-codec-cvdecompress-heap-overflow-ms10-055/
http://multimedia.cx/mirror/cinepak.txt
《漏洞戰(zhàn)爭(zhēng)》83頁(yè)-90頁(yè)
