kill.exe溢出漏洞分析与EXP讨论( 二 ) _小知识

文章插图
此外，图中还可以发现kill.exe开启了CFG保护，即有/guard:cf标记。但是由于笔者的分析环境是winXP系统，所以暂时不考虑CFG保护。
因为存在Safeseh保护，所以EXP变得更加麻烦。绕过Safeseh保护最好的方法，就是不使用覆盖SEH结构的EXP技巧，而是直接去覆盖函数返回地址或其他关键栈数据，而这显然是不可行的。考察被kill.exe加载的其他模块，发现全部都有/Safeseh标记，这就使得通过未启用/Safeseh的模块绕过Safeseh变得不可行。
不过，需要明确一点，kill.exe在win7环境下是自动开启DEP和ASLR的，截图如下：
而在winXP环境下，并没有开启DEP：
至于为何在winXP环境下，并没有开启DEP的原因，笔者并没有考证。
暂不考虑未开启DEP的原因，既然kill.exe没有开启DEP的话，那么只要保证异常处理函数不在任意模块之中，且不在栈中，那么就可有效的绕过Safeseh 。下面，笔者尝试用该方法过掉Safeseh保护。首先，观察进程空间内不属于任何模块的地址空间：

文章插图
以上地址都是不可取的，原因如下：如果打算让kill.exe触发异常处理函数，必须赋值很长的数据导致向栈之后的不可写地址写入数据，那么所有的写入内容不能包含空格、换行符以及空字符。而以上所有这些地址的最高位字节均为0×00，这个字节将终止栈的覆盖过程，原因见第1节中的分析。
此外，还有另外一小部分不属于任何模块的地址空间：
在这一部分地址空间中，可以用metasploit中的工具查找pop pop retn指令串，其结果如下：

文章插图
当笔者尝试使用这些地址的时候，发现这些地址无法与ASCII码或者GBK码对应。这里捎带一提，kill.exe是可以接受GBK编码的字符(简体字、繁体字等)，虽然这可以扩大可用的字符数量，但并没有什么帮助。
3.3 覆盖其他关键数据
可以观察从覆盖起始点，到stack cookie之间的所有栈空间，并未发现任何有价值的关键数据，即便将其完全覆盖成错误数据，程序也是可以正常运行，并在退出漏洞函数时清理了包含错误数据的栈空间。
到此为止，笔者并没有找到有效的EXP方法，暂时决定先搁置此版本的kill.exe，下面开始考察其他版本的kill.exe工具。
4. 另一个版本的kill.exe分析
在第1节中，笔者提到了另一个版本的kill.exe工具，该版本的kill.exe工具同样有GS和Safeseh标记，无DEP，但也没有guard:cf标记。
此版本的kill.exe工具在栈溢出时的关键代码与第2节分析的内容略有不同，如下图所示：

文章插图
上图中，关键的变量名已经标出，分别是source、temp和destination，这三个变量的含义正如其名称所示。
此版本的kill.exe在溢出时，会覆盖destination变量，从而使得可以对覆盖的内存地址和内容进行很小限度的控制。但这是否可以导致有效的EXP，就留给有兴趣的读者自己分析吧。
5. 结论
按照本文的分析结果来看，Microsoft的各种安全机制已经非常成熟，非常可靠，在这诸多的安全防护机制之下，MS的产品即便存在一些漏洞，也无法实现其有效利用，尤其针对传统的简单单一漏洞。当然，在更复杂的情况和环境之中，通过多个漏洞组合或者其他逻辑上的错误漏洞，也确实存在一些可被利用的漏洞。而对于非MS产品，那就另当别论了。
【kill.exe溢出漏洞分析与EXP讨论】此外由于笔者知识有限、才疏学浅，笔者个人无法实现有效的EXP并不代表其他分析人员同样无法实现，在这里笔者由衷地期待能够得到这些高人的指点。对于不太熟悉本文内容的读者，希望这篇能带来一些启发和帮助。