czy
发贴 44
注册 2005-11-27
状态 离线
|
我来顶一下.最近刚好也在看这个洞.总结下好象有两个利用思路:
1.一个是EMM的,就是先在STACK的低地址构造5C,然后第二次发包来找这个在STACK的低地址残留的5C.
这个办法我觉得不稳定的主要原因是在不同版本的NETAPI32下从这个残留的5C到WCSCPY的RET的距离是不一样的
而且有可能这个距离超过208H,那么利用将不会成功.
2.Polymorphours哥的方法,我理解的是在STACK的低地址总是有5C的,只是离WCSCPY的RET一般很远,所以第一次触发洞先把大SC放到这儿,然后第二次发触发包构造的超长PATHNAME串刚好是5C的长度,这样那个CAN...函数的局部变量pathlen就肯定是5C.然后WCSCPY的目的地址就是从这儿开始COPY的,而这个距离到WCSCPY的RET在多个版本下都是相同的.至于不超过5C的长度放一个EGGHUNTER足够了.这个办法不足之处应该在于第一次触发时找不到5C的话,就出错了.
我在想能不能把两个方法结合一下:
1.先发包在STACK的低地址够造一个5C.
2.发触发包放大SC(同时这个SC也可以包含跳转地址,这样如果构造的SC刚好能够覆盖RET的话就直接利用)
3.发触发包(包中PATHNAME的长度=5C)执行EGGHUNTER.
另外这个洞EMM的SC没有考虑把NetpwPathCanonicalize(buf, (wchar_t*)out, 1000, L"", &q, 1);
的倒数第三个参数设为"."号,在XP SP2原始的2180版本不能利用洞.
另外我看了下在CanonPathName函数的局部变量中还有prelen,也就是NetpwPathCanonicalize函数的倒数第三个参数的长度,可不可以这个参数长度弄成5C.这样的话buf参数中就可以直接放大SC了. |
|