[技术文摘]CVE-2015-8651漏洞原理分析 [复制链接]

CVE-2015-8651是对domain  memory执行相关操作的opcode在执行过程中没有很好的对访问地址的范围进行判断从而导致整数溢出漏洞，它的漏洞形成原理和CVE-2013-5330以及CVE-2014-0497相似，以下为实际操作
1.使用JPEXS Free Flash Decompiler 打开样本，能看到相应的脚本:

图片:1.png

2.找到溢出的代码位于Bymitis类中，Bymitis在初始化的时候会判断当前是不是在IE浏览器中运行，如果不是IE就退出。接着会判断Flash player的版本，然后根据版本执行相应的代码。本次分析使用的Flash Player的版本是13.0.0.128,因此会进入函数cidkedie中执行

图片:2.png

3.发现JPEXS Free Flash Decompiler反编译的结果相與动态调试的结果不符，发现AS反汇编代码有问题

图片:3.png

4.从cidkedie的代码中可以看到domain memory指向的是一个长度为0×1000的ByteArray数组，它的名字是fastmemory.这个数组的前几个字节被填充为m3mory，后面跟随一个计数，记录该函数被调用的次数。因为使用了堆喷射，所以该函数会被反复被调用，以保证能够访问到特定的内存

图片:4.png

AS脚本生成的JIT代码如下:

图片:5.png

5.发现0×80001004+0x7FFFFFFC整数溢出为0×1000.这个值就写入到了domainMemory的内存区之外

图片:6.png

6.创建1280个uint对象，然后将它们的长度改为1022.每个uint对象的内存第一个DWORD的值为1022,如果uint对象的内存刚好位于domainMemory内存的后面就可以修改这个值，然后就可以访问任意内存，接着可以在可访问的内存范围内创建object对象，找到object的虚函数表，修改函数指针，执行shellcode.，cidkedie函数被调用两次后就会发现domainMemory的后面紧跟着一个uint对象

图片:7.png

图片:8.png

0x9c28000向下0×1000处的内存

图片:9.png

第一个值为0x03FE(1022),第三个值为0×12345678(305419896),此为上面创建的uint对象

图片:10.png

前后对比后就可以发现uint对象的长度被替换为0x3FFFFFFF,这时候uint对象的内存变得很大，可以访问任意内存了


补充相関指令：
1.这两条指令执行完后eax=0x3FFFFFFF

图片:123.png

2.这条指令执行完后ESi=0×80001004.

图片:456.png

3.两条指令执行完后:ebx为ApplicationDomain.currentDomain.domainMemory指向的内存地址，ecx为ApplicationDomain.currentDomain.domainMemory的大小即0×1000.

图片:789.png