微软DirectShow MPEG-2视频0day漏洞深入分析

正规的Script是绝对不会用*.jpg的，这就像古装片里黑衣人一样，告诉你就是做坏人的。其中的go.jpg是SHELLCODE，而go1.jpg则是引发漏洞的JScript。
hxxp://vipguibin22.3322.org/aa/go1.jpg 片段：
var myObject=document.createElement('object');
DivID.appendChild(myObject);
myObject.width='1';
myObject.height='1';
myObject.data='./logo.gif';
myObject.classid='clsid:0955AC62-BF2E-4CBA-A2B9-A63F772D46CF';
通过调用0955AC62-BF2E-4CBA-A2B9-A63F772D46CF打开hxxp://vipguibin22.3322.org/aa/logo.gif触发漏洞。
现在让我们打开注册表，搜索0955AC62-BF2E-4CBA-A2B9-A63F772D46CF，就可以搜索到BDATuner.MPEG2TuneRequest，以及提供这个服务的DLL，C:\WINDOWS\system32\msvidctl.dll
漏洞原理分析：
该网页通过hxxp://vipguibin22.3322.org/aa/logo.gif触发漏洞，漏洞代码在C:\WINDOWS\system32\msvidctl.dll之中，既然已经定位到这两点，我们就可以用调试器来进一步分析了。
以XP SP2为例，在CreateFileW下断点，跟踪到打开logo.gif为止，接下来在ReadFile下断点。断下来之后，寻找堆栈中返回到 msvidctl.dll的地址，这里就是读取logo.gif作处理的代码了。继续一步一步跟踪代码的执行，一路无事，直到：
59F0D545 8B5D EC MOV EBX,DWORD PTR SS:[EBP-14]
59F0D548 83C3 20 ADD EBX,20
59F0D54B 3973 08 CMP DWORD PTR DS:[EBX+8],ESI
59F0D54E 895D EC MOV DWORD PTR SS:[EBP-14],EBX
59F0D551 ^0F85 83FEFFFF JNZ msvidctl.59F0D3DA
代码执行到59F0D54B时抛异常了。而堆栈中的情况：
0013C6F4 00000000
0013C6F8 FFFFFFFF SEH 链尾部
0013C6FC 0C0C0C0C SE处理程序
0013C700 00000000
0013C704 /0013C750
注意红字部分，SEH被覆盖了，而该地址的内容即为ShellCode
0C0C0C0C 90 NOP
0C0C0C0D 90 NOP
0C0C0C0E 90 NOP
知道黑客是通过修改哪里得到执行权的，那么我就可以重新跟踪这段处理代码，每跑过一段代码都查看0013C6FC处是否为0C0C0C0C。最后定位到下面代码。
59F0D6BF FF15 A012EE59 CALL DWORD PTR DS:[<&OLEAUT32.#15_SafeAr>; OLEAUT32.SafeArrayCreate
59F0D6DA FF15 A412EE59 CALL DWORD PTR DS:[<&OLEAUT32.#23_SafeAr>; OLEAUT32.SafeArrayAccessData
59F0D6E6 6A 00 PUSH 0
59F0D6E8 FF75 D8 PUSH DWORD PTR SS:[EBP-28]
59F0D6EB 8D4D 08 LEA ECX,DWORD PTR SS:[EBP+8]
59F0D6EE 51 PUSH ECX
59F0D6EF 57 PUSH EDI
59F0D6F0 FF50 0C CALL DWORD PTR DS:[EAX+C]
59F0D6F7 FF15 A812EE59 CALL DWORD PTR DS:[<&OLEAUT32.#24_SafeAr>; OLEAUT32.SafeArrayUnaccessData
0013C6FC处是在执行59F0D6F0后被修改的，而59F0D6F0处的作用为读取文件内容到内存之中。此处内容写为简单的伪代码为
LPBYTE pData;
SafeArry = SafeArrayCreate() //建立一个安全数组对象
SafeArrayAccessData（SafeArry, &pData） //安全数组引用+1，返回安全数组的数据指针
ReadFile &pData //将文件内容读取到指针中
SafeArrayUnaccessData（SafeArry） //安全数组引用-1。
跟踪到这里，原因一目了然——是一个代码Bug导致的。ReadFile并没有写到安全数组数据指针指向的内容，而是把保存指针的堆栈当作缓冲区改写了，导致黑客可以通过构造一个特殊的文件，控制程序的堆栈区域。刚好SEH 保存在堆栈之中，用这个获取执行权是再好不过了。
指针的使用在C语言中一直存在隐患，一不小心就出错，微软的程序员也不例外。当你每天写上千行代码的时候，当你加班赶项目进度的时候，你是否也会在写下&pData之后，在下一个需要使用pData的地方，鬼使神差地又写上一个&pData呢？
一个程序员的小疏忽，引发了一个波及全球的漏洞攻击。