纸上得来终觉浅,绝知此事要躬行  --陆游

最近《漏洞战争》快看完了，也跟着书把漏洞分析了一遍。虽然也有自己的思考，但绝大部分都是复刻书中的操作。以我浅薄的知识，甚至有的时候无法理解某些操作，只好先跟着做，等快分析结束时才能恍然大悟。在分析书中下一个漏洞时，总是有种无从下手的感觉。所以就想着自主分析一下漏洞，顺便沉淀一下所学知识。

CyberLink LabelPrint是一套快速简易的光盘卷标制作软件，支持最新lightscribe光盘封面刻录技术。 CyberLink LabelPrint 2.5中基于堆栈的缓冲区溢出允许远程攻击者通过lpp项目文件中的（1）author（INFORMATION标签内）、（2）name（INFORMATION标签内），（3）artist（TRACK标签内）或（4）default（TEXT标签内）参数执行任意代码。

此漏洞的利用代码在Metasploit有集成，我们以一个弹计算器的形式生成一个exploit：

生成的exploit我们打开后，根据漏洞描述可以确定是name属性造成的堆溢出：

我们打开exploit可以看到calc成功弹出，接下里就是分析漏洞成因了。

首先我们运行LabelPrint，然后打开windbg，并用windbg附加LabelPrint.exe运行，并打开msf.lpp，打开后触发异常：

可以看到这是调用MSVCR71!wcscpy的时候，由于循环复制内存数据到栈空间时，未能检测复制的内存大小，导致覆盖到00130000这个只读内存空间，最后造成异常。同时我们再看看栈发生什么变化：

可以看到栈已经被破坏了，反汇编MSVCR71!wcscpy：

可以看到wcscpy没有自己的栈帧，同时也没有任何改变栈的操作，所以栈顶一定存放着返回地址。

可以看到函数在004657c2这个地址调用wcscpy进行内存拷贝，我们将此函数暂且称为vulfunc。用IDA中打开此函数：

现在我们确定了漏洞函数，重新附加在vulfunc函数头下断:

断下后运行会发现再次断下，我们在第5次断下的时候再运行才触发异常

重新加载在第5次断下时，查看此时esp，确定函数调用过程：

函数在00410c21地址处调用了vulfunc函数。再用ida查看此函数：

现在我们知道为什么vulfunc要调用5次了。而且这些属性正好和exploit中一一对应。但是在vulfunc中仍进行了两次if判断才最终执行wcscpy。所以想要继续确定执行流程，还得分析vulfunc函数。重新加载在vulfunc函数头下断，在第5次断下时单步跟踪确定执行流程：

对应的C代码如下

上面先是调用VariantInit初始化pvarg，pvarg是变体类型Variant，Variant 是一种特殊的数据类型，除了定长String数据及用户定义类型外，可以包含任何种类的数据。Variant 也可以包含Empty、Error、Nothing及Null等特殊值。VARIANT数据结构包含两个域(如果不考虑保留的域)。vt域描述了第二个域的数据类型。
之后取DOMNamedNodeMapList对象及其虚表指针。
我们接着往下走：

对应的C代码如下：

上面调用了DOMNamedNodeMapList::getNamedItem将DOMNode对象传递给v10，接着跟踪：

对应C代码如下

VarType如下

由上可知通过调用DOMNode::get_nodeValue将pvarg.vt赋值为8，同时取name属性中的值放入pvarg.bstrVal中。
接下来就是一些数值传递：

最后调用拷贝函数，在此之前需要确定拷贝的目标地址：

拷贝的目标地址为0012e8a8。

由于程序在调用vulfunc读取属性值的时候，没有计算属性值所占用的空间大小，最终在复制时导致溢出。

源码如下：

可以看到exploit将0x42作为nop，以ABC中随机一个字符作为填充。将以上代码优化后如下：

接来下我们单步调试确定各个区块的作用

先是用junk填充790字节，再用0x61，0x42覆盖掉SEH指针 可以看到地址为0x12EED4，用target['Ret'] 覆盖seh Handler ：

当覆盖到0x00130000这个地址的时候触发异常进入0044002c执行：

此时堆栈情况如下，可以看到执行两次pop后ret到0x12EED4

正好跳转到我们的覆盖的SEH结构上,0x61为popad，执行后提高了我们的esp 同时注意此时的edi为0012EED4。

执行完此区块后的寄存器情况：

此区块单纯的将esp提升到0x0012f655， 提升的目的是什么，为什么是这个地址？而且msf对此区块的注释是我们需要对RET地址进行编码，因为RET（\xc3）被称为坏字符。现在我们只能记住此地址，接着向下分析。

此时堆栈情况如下：

将0012EED4写入0012F651地址msf的解释是为了对齐堆栈。我们暂且不管这个操作，接着将C300C300写入0012F64D这个地址，貌似上面一切改变esp的操作都是为了让我们将 C300C300写入00126F4D这个地址。根据上面解释0xc3代表ret指令。我们在汇编窗口查看0012F64D+1这个地址，可以看到此汇编指令变成了ret。为什么不直接输入c3指令，反而废了这么大功夫就为了生成0xC3。在msf.lpp文件中任意位置改成0xC3后用程序打开后显示加载项目设置时出错，请确认您选择的项目类型正确。

可以看到此区块的作用是将0012F651地址中的0012EED4取出给eax，再将eax提升到0012F6D4后压入栈：

为什么要这么操作，还得接着向下分析。

pop esp，所以上一个区块是为了将eax给esp，此时esp为0012F6D4，此时堆栈情况如下：

之后执行pop eax是为了将0012F6D4里的0x0032007B取出给eax。0x0032007B这个值是不是很熟悉，我们看第五个区块的末尾：

这里预先存放了0x0032007B。接着一顿操作将eax变为7C32537B后压入栈：

接下里一路执行直到0012F64E地址处的ret指令。执行ret指令跟进7C32537B地址发现这是一个call esp，而此时的esp是0012F6D8。
现在我们明白原来预先在0012F6D4这个地址里放入0x0032007B不是随便找的地址。我们既拿到了0x0032007B又把堆栈提高到了0012F6D4，之后的操作也是只是对堆栈进行小修改。最后通过7C32537B处的call esp使程序跳转到0012F6D8处执行。之后一路滑行到达第六个区块

这里前两句可以理解成将edi赋值给eax，edi的值在哪来的，还记得最开始的时候的popad吗，那时候将edi变为0012EED4。接着向下走对eax一顿操作，经过一个nop后终于到达了我们的payload。此时eax和eip都指向我们的payload。查看此时payload发现已经进行了编码，看不出来什么东西。跟踪payload时会发现payload头部会有一个解码的程序，这块我就不过多赘述了。最后弹出计算器。

此漏洞我在网上貌似没有找到有人分析过，所以可能有的地方分析的不对，遗漏错误之处请大佬们斧正。学习的同时顺便也想把研究成功分享一下，在下文笔可能也略显粗糙，请多多海涵。

https://www.exploit-db.com/exploits/45985
https://baike.baidu.com/item/Variant/4668832?fr=aladdin

[培训]内核驱动高级班，冲击BAT一流互联网大厂工作，每周日13:00-18:00直播授课