ms08067 菜鸟级分析

0x01 前言

ms06040和ms08067都是在netapi32.dll中同一个函数NetpwPathCanonicalize中出现问题。但是ms06040是由于在拼接路径时的问题,而ms08067是不常见的往低地址搜索导致的覆盖溢出。

0x02 漏洞简单描述

在导出模块netapi32.dll中函数NetpwPathCanonicalize中的CanonicalizePathName函数中。有一片伪代码是这样的

就是在我画圈的这个函数里的问题。
说白点,他就是自动分析./和../的问题。把路径弄规范点。打个比方
输入:/aaa/./bbbb
输出:/aaa/bbbb

输入:/aaa/bbb/../ccc
输出:/aaa/ccc

这都是正常情况下,可问题来了。
输入:/aaa/../../ccc
这个会怎么样?
输出:/../ccc

虽然输出/../ccc 可这里明显多了一个/../ 他就不处理了嘛?

实际上,这个函数内部先是这样的。
实例输入: “/aaaa/../../dddd” 栈地址:0012FFCC
他先记录第一个/位置指针,然后向右搜索第二个/指针,在这个过程中判断是./还是../ 还是普通的字符串,然后各自进入不同的分支代码。
所以第一次的wcscpy函数后,0012FFCC 指向的值就变成了(/../dddd)

然后他很奇葩,奇葩到 0012FFCC-1的位置和0012FFCC判断,并且循环自减1寻找0x005c(这边发生了向低地址搜索的溢出)。找到后再重新从0012FFCC位置向右搜索判断是./还是../还是普通字符串的分支。由于我们还有第二个../
所以。。。第二次的wcscpy就。。。。会向前覆盖数据(平时我们接触的溢出都是向高地址(向后覆盖))。。。

由于我们知道进入一个函数,栈地址都是低地址移动的,所以当第二次wcscpy覆盖好数据后,当他返回后就溢出了,覆盖了返回地址,并且当时版本此函数并没有引用 gs机制。所以。。。。就。。

强烈建议各位看官先自己动手调试几遍过程。不然,0DAY2的资料,网上的资料。我说的这些,基本都是看不懂的,哪怕是图文并茂,一定要动手

0x03 稳定利用方案

参考文章
MS08-067的稳定利用方法
6 [原创]EMM’s MS08-067 exploit 原理分析

通过刚刚的口述分析知道,想要利用漏洞,必须在溢出越界的地址需要找到005c,并且字符好像有限制,好像不能超过0x207个还是多少个,并且每个版本都会造成005c的位置差异。甚至超过字符长度限制,导致溢出失败。所以。。。。高手们想了一招。就是在能覆盖到的内存地址里面尽量制造出0x005c来。所以最后的答案是NetpwNameCompare这个函数,参考2篇文章。基本上,对这个老漏洞就通关了。

发表评论

电子邮件地址不会被公开。 必填项已用*标注