CVE-2018-4901的研究

0. 前言

上个周末在 FreeBuf 上看到Adobe Acrobat Reader中存在远程代码执行漏洞 这篇文章后，决定自己尝试去复现一下这个漏洞，至少能弹个计算器吧，结果一些事情出乎意料，这里把自己的研究过程写下来。

1. POC构造

根据国外的一篇文章 talos 中介绍,漏洞原理是在 pdf 中 trailer 内部的ID字段如果过长，在执行JavaScript脚本this.docID的时候会触发漏洞，漏洞模块位于一个dll文件EScript.api中。那么，是应该先构造javaScript还是先构造trailer后面的ID呢？javaScript我是通过Acrobat Pro DC添加上去，如果先构造trailer，那么会被Acrobat Pro DC修复，所以先构造javaScript。另外，最初的文档怎么才能包含trailer呢？说实话之前并不熟悉pdf文件格式，在进行了很多尝试之后，发现使用wps将空白doc文档转化为pdf之后，文档很简洁，并且包含有trailer。那么流程就很清晰了：

1.1 生成包含trailer的pdf

1.2 javaScript的构造

使用Acrobat Pro DC编辑刚刚生成的文件，使用javaScript工具，在保存pdf文件的这个动作的时候添加javaScript命令this.docID即可。

1.3 trailer的构造

在保存上面的文档后，使用notepad打开文档，将trailer后面的ID改为 ,需要更改的地方有两处。

1.4 poc效果

注意前面构造的javaScript是在保存文档的时候触发，但是如果开启沙盒，保存文档时就总是弹出另存为进而无法触发漏洞，所以要先设置Adobe,ADOBE 保存PDF文件，总是弹出另存为的解决办法

测试：在文档中添加注释，然后点击保存，Adobe崩溃，模块为EScript.api

2. 调试分析

2.1 崩溃原因

使用OD载入AcroRd32.exe，并打开文档，之后就在模块中就可以看到EScript，根据TALOS的那篇文章，在其中搜索触发漏洞的代码。

这段代码简单的说就是，我们构造的样本中ID的字符串已经被转化为16进制数了，hexStr(“AAAAAA..”) -> hexArray（0xAA 0xAA….），而触发漏洞的这一块是将hexArray（0xAA 0xAA….）又转为hexStr(“AAAAAA..”) .

但是漏洞具体是如何触发的需要结合动态调试，在循环开始出下断点，和之前触发崩溃的方式进行相同的操作，程序会断在断点处，可以获得如下图所示的初始信息。

一开始，edx指向hexStr，edi指向hexArray，并且hexStr的首地址就在hexArray首地址上方0×100的地方。esi是循环的次数。

具体看看每一项的数据的情况：

hexStr是目的地，也就是它没过返回地址；

hexArray很奇怪，只有0×80个0xAA,我们传入了0×200个‘A’,那么理应由0×100个0xAA；

esi是循环次数，值为0×100,正好符合我们的预期。

假如没有啥保护机制,我们要淹没的返回地址是0x2Bc8c8处的0x693a3168

进一步观察，0×80个0xAA正好转化为0×100个‘A’,那么执行0×80次，就应该会到hexArray首地址之前了。这里下一个条件断点，让它执行0×80次

但是一切还会往后继续，如果再执行0×40次，那么hexArray就会被自己后面的数据给覆盖。同样下条件断点，再执行0×40次

记得之前要淹没的返回地址吗，它在这个地方

那么只要再执行0xC次，它就会被覆盖了

同样是下条件断点，继续执行

地址被覆盖为0×30303030了

而触发漏洞代码片段下方的两个函数分别是string()和__security_check_cookie，这里先不去管它。因为我们能控制的只有0×80,是真的只有0×80吗?

2.2 疑问

结合IDA来分析分析

可以看到，在漏洞触发之前HexArray的数据来源有两种情况：

1.memcpy(&v17, v14, (size_t )&v15[1]);

2.nCircleIndex = ((int (__cdecl **)(int, int, char , signed int))(dword_23A59CB0 + 320))(a2, a3, &v17, 0×80);

对于1，(size_t )&v15[1]在其上的if判断中被限制为<=0×80.

对于2，其中的参数被设置为0×80.

对于第2种情况，我们还需要调试来验证是否是这个参数限制了hexArray

2.3 OD动态调试验证

我们在push 0×80下断点重新触发漏洞中断下来了，说明hexArray的数据来源是第二种情况，然后我们将push 0×80改为push 0×100

执行到漏洞开始处，内存转到edi，发现现在有0×100个0xAA了，说明之前的判断是正确的

3. 结论

我们能够控制的只有拷贝的次数和拷贝的前0×80个字节HexArray的内容。而函数分配给HexStr 0×100固定大小的栈空间，程序流程是HexArray转化到HexStr，所以我们可控的能覆盖的空间也就只有HexStr那一块空间。以上是我关于CVE-2018-4901的研究。另外，经过尝试,不是trailer，其他标签下的ID如果超长也会出发漏洞。