几个星期前，网络上有人发现了一个新的Adobe Acrobat/Reader零时差漏洞，没多久就立刻出现专门利用此漏洞的攻击。从技术角度来看，此一攻击最引人注目的地方，在于它运用了返回指标漏洞攻击（Return-Oriented Exploitation，简称 ROP）技巧来规避Windows的数据执行防止（DEP）安全机制。此外，它还使用了二阶段的攻击程序代码（shellcode）来执行恶意软件。其第一阶段运用 ROP 技巧来加载第二阶段的程序。第二阶段才是恶意行为真正执行的地方，而且是透过JavaScript来将.PDF档案内的程序代码加载内存。
从这类威胁我们可以看出，专门攻击漏洞的恶意软件真是越来越精密。尽管Microsoft等厂商已尽量加入一些新的技术来防止漏洞攻击，但看来黑客也不是省油的灯，使用者的日子也不会太好过。
静态分析
当我们在分析.PDF档案时，我们在内部发现了一个很可疑的FontDescriptor（字型描述）对象。（FontDescriptor 对象用来描述.PDF档案内所用到的字型。）
这笔字型数据采用FlateDecode方式编码。当我们将它解?之后，我们看到一个SING表，并且立刻发现了可疑的内容。其uniqueName（独特名称）字段应该是一个采用7位ASCII编码且用NULL字符结尾的27字符字符串。
但是，此处的数据却超过28个字符。这就是典型的缓冲区溢出。
除错
我们从静态分析得知此漏洞攻击使用了.PDF档案中的哪一部分数据。接下来，我们要运用程序除错器（debugger）来验证我们的看法，并且看看它实际上如何运作。当这个恶意.PDF档案在Adobe Reader中开启时，会呼叫strcat函式。让我们来看看此函数调用的来源缓冲区内容。
我们已看过「A8AAAAAA…」这段内容。这就是先前uniqueName字段的实际内容。而目的地缓冲区则是一个固定大小的堆栈。正是因此才会造成缓冲区溢出。
在缓冲区溢出之后，堆栈上的一个函式指标就会被覆写成0x4a80cb38。接着后面会呼叫这个函式指标，攻击者就因此获得程序执行控制权。
返回指标漏洞攻击
其实缓冲区溢出本身并不是太严重或太不寻常的问题。但是，这项攻击利用了ROP技巧来避开Windows用来防止漏洞攻击的DEP机制。DEP机制可以防止系统执行非可执行内存分页中的内容。
但ROP技巧会覆盖已加载的可执行码来让自己的程序执行，巧妙地避开了DEP机制。ROP背后的逻辑是，只要程序够大，就能让攻击程序运用现有的程序代码来组成一个程序代码“串行”。
此攻击的作者选择了Adobe Reader的icucnv36.dll组件为目标。此组件并未设定使用地址空间配置随机化（Address Space Layout Randomization，简称ASLR）功能，因此才会轻易成为 ROP 攻击的目标。前述的地址（0x4a80cb38）就是icucnv36.dll内以下这段攻击程序代码的起点。
- 4a80cb38 81c594070000 add ebp,794h
- 4a80cb3e c9 leave
- 4a80cb3f c3 ret
只要修改一下堆栈指针，这段程序代码就会变成 ROP 串行的起点。后面接着的程序代码则指向用来做为ROP串行的堆栈数据。堆栈数据内容则是使用恶意.PDF档案内的JavaScript来加载内存内。以下是一段这项攻击所用到的程序代码：
框出来的部分经过一些置换和反跳位运算之后，最后在内存内是一个双字组（double word）大小的数值：0x4a801064。
真正具备恶意行为的第二阶段攻击程序代码一开始也是先由JavaScript加载内存内。在经过解?之后，真正的程序代码应该像下面这样：
- %u52e8%u0002%u5400%u7265%u696d%u616e%u6574%u7250
- %u636f%u7365%u0073%u6f4c%u6461%u694c%u7262%u7261
- %u4179%u5300%u7465%u6946
这是原生 x86 机器码，用来执行真正的恶意攻击。
回到堆栈指针调整好后的第一阶段ROP程序，其程序代码会搜寻icucnv36.dll的某些部分，并且呼叫几个API函式：
呼叫CreateFileA来建立一个名为“iso88591”的档案（?名不重要）。
呼叫CreateFileMappingA，指定flProtect=0×40（让档案可执行）。
呼叫MapViewOfFile来映像刚才建立的档案。
呼叫memcpy来将第二阶段的程序代码复制到缓冲区，也就是此映射共享档案的开头。
接着，程序跳到映像档案所在的缓冲区开头来执行。由于此区为可执行的内存，因此就能避开DEP保护机制。
