FLASH 0day(CVE-2018-4878)从POC到利用

这是360 A-TEAM的第【5】篇文章

本篇文章，360 A-TEAM 将为大家介绍FLASH 0day(CVE-2018-4878)如何从POC到利用。

声明：本文由ze0r@360 A-Team原创，仅用于技术研究，不恰当使用会造成危害，严禁违法使用，否则后果自负。

0×00 前言

这篇文章没有前言，简单粗暴，干货满满~下面我们就开始吧~

0×01  在野EXP

一开始我们下载到了当时在野的EXP，用FFDEC查看AS脚本，关键触发点如下：

从反编译的脚本中，可发现除了布局内存外就是这两个方法，主要就是以一个§\x05§为参数初始化了一个drmManager对象，之后就将§\x05§赋值为NULL，而§\x05§为：

之后在github上发现已经有人发布了POC，而代码完全一致，只不过把乱变量名变得有意义了，而且也可以直接编译生成。故分析依照此POC进行。

前面已经说过，除了布局内存的代码外，就是初始化并赋值后建立了一个监听器。在POC中exploit方法中只留下这段代码，编译运行：

打开稍等片刻就会崩溃到调试器，查看：

可见直接使用ecx传递了一个对象，在IDA中也确认这是一次虚函数调用。

根据汇编代码可断定，ECX偏移0x0c处为某对象指针，而此对象已经全是0，造成了悬挂指针。再看AS3脚本中，把一个MyListener（实现了DRMOperationCompleteListener接口）类型对象赋值null。所以可猜测ecx->0x0c为MyListener对象。下断此时ecx这个对象的构造过程：

大致可判断此对象共5个方法，triggerVul即面触发崩溃的方法。查看引用共有2处：

反汇编确认赋值方法为1037a150：

windbg中下断，单步几次后查看对象内存：

确认此对象0x0c处为DRMOperationCompleteListener实例指针，即DRMOperationCompleteListener实例在被置null之后被垃圾回收，而在对象中还留存着实例指针造成悬挂指针问题。

0×02  POC利用

而在POC的利用中，则是利用双重释放内存来利用此漏洞。如下：

由于在代码中，在出现异常后又new了一个新的MyListener对象，由于同是Mylistener对象大小相同，所以内存管理器会仍然分配这块原来MyListener对象所在内存给新对象（只要没被占用）。而之后代码drmManager从未被使用，所以垃圾回收会释放drmManager对象，同样，也会把drmManager对象成员释放（减少引用计数），于是0x068c0100会再次被清除回收：

在清除完成后，AS3中的danglingpointer变量仍然指向这块区域，所以在POC中，也是定时查看danglingpointer的成员变量是否被改变来判断是否已经完成内存释放。而之后大量申请内存以再次被内存管理器分配此内存完成占用。在偏移0x70处下写入断点（因为重启了调试器，故下面截图中地址并不完全相同）：

可以看到Mem_Arr已经成功占位，正在写入变量默认值。完成后可得内存布局：

可见Mem_arr的数据区域为0x054a815c-0x054a819c(position=0x31)。其中0x38383838为改写的Modify对象标记，即：

AS3代码中，PwnBuffer主要设置成员o1的成员变量值，下写入断点得到布局：

从POC注释中我们知道danglingpointer.a14为m_buffer地址，而a31为o1对象，而查看上面的布局，发现有明显的故意错误（0x54a818c已经被错误的改写为0xfffffff0），修正后：“this.danglingpointer.a30 =this.danglingpointer.a14 - 0x10;”。修正后布局：

正确改写o1指针后，调用   PwnBuffer则更改了arr[0]属性，之后可成功读取内存：

此时由于arr[0]长度已经被设置成0xffffffff，故可读写进程任意地址内存：