关于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方法来占坑。不好意思,这里打了下个人广告,可惜公众号app不能直接插入书籍广告,不然就广告彻底一些🤑