批处理解析漏洞[贰]

0x07

我打开 Visual Studio 2010和cmd.exe进程,使用“简单”内存泄漏批处理文件(^),通过装置中断过程,使得解析器处于错误状态。检测完毕后,使用Process Explorer去验证我正调试的是什么模块,我有能力跟踪大量的代码流,在解析器中寻找 ^  符号(hex 0x5E).

从下面的整个流程,我们可以看到问题所在。

注意,为了文章简洁大方,剔除了许多

 

基于以上过程,我能够确定cmd.exe 解析代码和以下代码差不多。

似乎,脱字符号后面就是问题所在了。

0x08

这个BUG是当检测到脱字符号(^)时,从文件中读取下一个字符(也就是直接就避开了脱字符号)。如果脱字符号是文件中最后一个字符,这就会导致一个逻辑错误,当调用get_next_char函数时,文件指针就会逐渐增加;在这种情况下,EOF已经被传递了。当命令解析器读取下一个输入时,EOF就被忽略了,本质上“重置”这个文件指针会得到EOF+1错误。在这种情况下,将文件指针EOF+1 调整到很大的负数区域,由于他的文件指针重置不为0,文件的解析依旧是从上次的地方开始。

这就解释了内存泄漏以及造成8k的情况(一个8k“读缓存”被填满),当然这也就可以解释递归问题。当在文件中检测到一个| 或者 &时 ,因为EOF BUG造成了没有返回路径,所以形成了无限递归。

有评论指出,并进一步验证显示,脱字符号(^)在文件的末尾是不存在这个BUG的,我正在检测反编译ASM,看是否还有其他的情况,为什么会出现这种情况。

0x09

在检测过程和思考可能存在的利用,我不认为它能够和MS14-019一般严重,但是考虑到它的易用性(以及轻松修复),我定义它是一个中级预警,因为大多数利用是需要用户自己运行批处理文件的。

这里是一个可以用来编写和启动“killer”批处理文件的vbscript

这个脚本会创建一个名为Killer.bat的批处理文件,和一个 ^ nul<^  然后自动运行它,这个脚本可以放到一个.vbs文件中并加入到startup中,或者放入excel宏中运行。

这行命令相当于创建一个名为Killer.bat的批处理文件( \r\n在文件的末尾,做一个正常的回显,因此错误不会显示)

作为一个概念验证,我创建这个vbscript(和其他测试批处理文件一样),将它放入我的startup已经注册表中。当我登录后过了几秒,系统开始变得很卡,最后不能使用了,因为脚本正在消耗我的RAM,这个脚本可以通过结束cmd.exe进程而终止,但是因为他们工作速度太快,你甚至可能没有启动任务管理器的时间,其就讲RAM消耗完了。除非进入安全模式,改变它,而不是修复!

我可以想象到一个场景,一个毫无戒心的管理员,要运行一个backup.bat 脚本,刚好这个BUG也在脚本里面,后面的你可以自由发挥想象了。但愿我不会看到这个exploits在DoS或其他一些恶作剧中被使用。

我还检测了各种管道途径,以及改道的“破损”脚本,目前最简单的攻击方式便是利用“快速”版本进行DoS攻击。我在Windows 98, 2000, XP, Vista, 7, 8以及sever版本(包括32位,以及64位)上测试了这个BUG。Windows 98上的命令提示符不会受到影响,但是后面的版本(包括command.com 当使用 cmd.exe 解析批处理)出于好奇心,我还在ReactOS 和 Wine 上进行测试(都没有这个问题).

译者注:全文大结局,由于小编对某些词汇不够理解,译文或许有诸多不当,或比较生硬,希望朋友们能够指出不当之处,我会在第一时间进行修改,谢谢大家的理解!

【翻译@91ri.org团队】