关于Adobe PDF 0day的故事

今天StarLabs 发布了他们之前在天府杯上用的adobe pdf 完整exploit，该漏洞是一个 JS API UAF漏洞，利用代码公布在github上，以及利用思路分析文章：https://starlabs.sg/blog/2020/04/tianfu-cup-2019-adobe-reader-exploitation/

去年天府杯上，Adobe Reader应该是最大的目标了，很多人打，但临赛前，很多人却退赛了。因为当时的比赛规则是奖金池固定，所有攻破团队来平分那笔钱，所以越多人参赛就越吃亏。但即便退赛了，一些攻破团队拿到钱再平分下也没多少了，最后还不如直接报ZDI，甚至可能还不如上HackerOne报个xss。挖个xss多久？可能几天，利用都不用写。但挖个pdf漏洞多久，可能挖洞一周，写利用一个月，这性价比自不必多言，因此这届比赛，奖金规则一直被圈内人吐槽。

当时在现场了解到，可能不少人的pdf 0day都是js api，这种通过js完成利用比较方便通用，当然其它非js模块的漏洞也同样可借助js堆喷利用。这些用js api漏洞的人最应该担心撞洞了，现场也有人用其它模块的pdf 0day，反正最后手上有个洞被撞没了。一个只在当最新版出现的漏洞，当时Project Zero报了一堆那个模块的漏洞，结果坑爹的Adobe修了漏洞1，却造就了漏洞2出来。在Adobe安全公告上，看到那个被撞的漏洞致谢上仍然写的是Project Zero的人（没错，未出现传说中的TFB)……

至少通过这件事情告诉我们，跟着PZ有肉吃！！！

Adobe的JS引擎用的是2013年左右的SpiderMonkey修改的，所以当初像domato这种js fuzzer神器出来之后，直接拿来fuzz，你都可以搞出一堆Adobe Reader的0day出来，也确实被刷了一波，看公告致谢时间，好像是我带的坏头?…

前两年，pdf中的图片解析漏洞盛行，被玄武的刘姓小哥刷爆了。当时如果我报10个此类漏洞，那么可能就会有3个撞洞，就是这么惨烈，连windows上xps这种偏门格式，都被撞，也跟360的撞过。

在此之后，被刷最多的pdf 漏洞，除了常规的js api外，postscript被国外安全研究员mr_me刷了不少，他写了个ps语法模板生成器去fuzz，产量颇丰。如果没记错的话，据他自己在Twitter上公布的，其2018全年在ZDI的收益是近20万刀，相当于140万元。之前他创办了一个公司，但公司员工就一人。没错，就是他自己，基本就是专职挖洞和培训。今年他入职360 vulcan了，远程办公。

最后聊点pdf的通用利用技术，毕竟本公众号是技术导向的，但请原谅我的排版和无图内容，因为本文是在手机上写的，且全程在车上完成。

上文提到的文章已经给出了完整的利用思路，整体而言：

1. 无论何种内存破坏漏洞，一些逻辑漏洞除外，首先都设法转换成任意读写。利用js array堆喷去内存布局，实现uaf的占坑，或其它越界写的后堆块填充，以实现写内容和位置的控制，而js array本身可读，进而实现信息泄露。

2. 覆盖虚表指针去控制eip。寻找上下文可用的虚表指针去实现劫持，像starlabs用CTextField去创建一批对象，目的就是用来覆盖它的虚表指针

3.绕过DEP和CFI。2019年3月左右，Adobe终于加入了CFI，导致常规的ROP失效。每次这种新安全机制出来的时候，最佳的绕过方式一定是先寻找未受保护的模块或代码块。回望过往的DEP、ASLR、CFI和PAC，无不如此。这次starlab亦然，他们直接搜索Adobe安装目录下的pe文件，若OPTIONAL_HEADER.DllCharacteristics & 0x4000 = 0，即代表无CFI保护，最后他们找到icucnv58.dll用来构造ROP，分配可执行的shellcode来达到任意代码执行。

除了第一步需要依赖漏洞上下文场景来转换任意读写外，利用的难点也是在此，而后续工作都是可以套路化。

可以看到，直至2020年了，Adobe的整体漏洞利用思路依然变化不大，仍是《漏洞战争》中各案例所分享过的方法，只是需要根据漏洞场景作些适配，比如寻找UAF对象同大小的对象，像starlab就用currentValueIndices方法来占坑。