测试版本:AcroRdrDC1700920044_en_US
漏洞模块: Escript.api
漏洞函数
修复函数
问题分析
拷贝对象的时候把DWORD类型的对象地址作为BYTE类型进行了拷贝，堆对象拷贝溢出漏洞。对象偏移在0x50的地方，也就是错误的位置。
Javascript里面喷射的对象代码。
修复方案
定位到问题很好修复。
ROP技术
使用EScript.api模块作为ROP执行地址，基址为69260000，ROP表如下.
- 0D130064 692E2803 EScript.692E2803
- 0D130068 692E2803 EScript.692E2803
- 0D13006C 692E2802 EScript.692E2802
- 0D130070 693F7084 <&KERNEL32.VirtualAlloc>
- 0D130074 69271784 EScript.69271784
- 0D130078 693EAF26 EScript.693EAF26
- 0D13007C 69278000 EScript.69278000
- 0D130080 69283AAA EScript.69283AAA
- 0D130084 6936F282 EScript.6936F282
- 0D130088 00010201
- 0D13008C 692E2802 EScript.692E2802
- 0D130090 692695C4 EScript.692695C4
- 0D130094 77842FB6 kernel32.VirtualAlloc
- 0D130098 69283AAA EScript.69283AAA
第一条ROP指令RETN在692E2803，为一条RETN指令。因为有ASLR保护，所以地址看起来不一样。
ROP指令不进行一一讲解，接下来通过ROP技术构造了一个函数VirtualAlloc分配一段内存。注意看下EAX寄存器的值。
EAX是0x90909090，adobe的javascript的堆喷射器里面也有0x90909090。
使用VirtualAlloc函数申请了一段可读可写可执行的内存，大小为66049字节。为什么呢?因为恶意pdf里面还有个pe文件，shellcode应该带有一个pe加载器，直接在本进程在内存执行pe文件。
接下来返回到了恶意内存中的shellcode继续执行。注意一下，前面4字节是0x90。说明那个是填充的NOP指令。
Shellcode
第一个功能就是在shellcode长度(0x2710字节长度)后面搜索一个4字节的标记0xBFAFBFAF。搜索标记的作用是定位PE头。
接下来用经典的fs:[0x30]技术定位kernel32的基址。
接下来通过解析PE文件搜索GetProcAddress函数的地址，这也是windows经典的shellcode技术。
使用GetProcAddress函数得到LoadLibraryA、VirtualAlloc、VirtualFree、VirtualProtect、GetModuleHandleA的地址
接着是PE加载器的经典功能，拷贝PE头、修复区段、重定位、填充输入表等等。
接着使用VirtualProtect函数改写PE为可读可执行可写。
最后调用PE文件的入口函数，因为PE是dll所以入口是DllMain。
这个dll只有一个功能，使用MessageBoxA弹一个对话框。
Dll的入口函数。
完事收工。
原文地址：https://mozhe.cn/news/detail/294
原文地址：http://blog.51cto.com/13520190/2119724