类型混淆漏洞原理与实例分析

1. 类型混淆漏洞概述

类型混淆漏洞(Type Confusion Vulnerability)是一种将数据类型A当做数据类型B来解析引用的安全漏洞，这种错误可能导致非法访问数据从而执行任意代码。这类漏洞通常发生在面向对象编程环境中，当程序未能正确验证对象类型时，攻击者可以操纵程序将对象解释为错误的类型。

2. IE/Edge类型混淆漏洞分析(CVE-2017-0037)

2.1 漏洞环境

• 受影响系统：Windows 7
• 受影响软件：Internet Explorer 11
• 分析工具：Windbg、OllyDbg、IDA Pro

2.2 漏洞原因

函数处理时没有对对象类型进行严格检查，导致类型混淆。具体来说，当处理HTML表格(table)元素的align属性时，IE错误地将一个整数数组对象当作虚表对象处理。

2.3 漏洞分析过程

1. PoC构造：

   • 定义了一个table元素，标签中定义了表id为th1
   • 在boom()函数中引用该表格
   • 使用setInterval设定事件

2. 崩溃分析：

   • 崩溃时eax作为指针引用了一个无效地址
   • 崩溃前一条指令是一个call指令，无效返回值来自这个调用
   • 通过逆向分析发现，正常情况下ecx参数应指向Layout::FlowItem::`vftable虚表

3. 关键函数分析：

   • Readable函数读取虚表中+4的值，为0时this指针赋值v1，随后v1+16后返回
   • 正常情况下，Layout::FlowItem::`vftable所属指针会被正确处理
   • 漏洞触发时，第二次调用该函数时ecx不是虚表对象而是int Array对象

4. 对象创建跟踪：

   • 使用条件断点跟踪两个对象的创建过程：
     • FlowItem::`vftable对应的虚表对象
     • 引发崩溃的int Array对象
   • 第一次调用Readable函数时ecx是正常的FlowItem对象
   • 第二次调用时ecx变为int Array Object

5. 漏洞触发机制：

   • boom()函数中引用th1.align导致Readable函数被第二次调用
   • 由于缺少对象属性检查，table对象被错误传入
   • 最终导致类型混淆崩溃

2.4 利用关键点分析

1. 控制流分析：

   • 在判断eax返回值不等于0后，会继续调用Readable函数
   • 后续有一个call edi指令，这是一个虚函数调用
   • 如果能控制edi就可能实现代码执行

2. 绕过保护机制：

   • 存在控制流保护机制CFG(call __guard_check_icall_fptr)
   • Windows 7系统未开启此保护，无需绕过

3. 内存控制：

   • 通过修改th1对象的width值为2000000
   • 允许将EAX值移动到堆喷射中的受控内存位置
   • 计算：0Xbebc200 = (2000000*100)在可控范围内

4. ASLR限制：

   • 所有加载模块均启用了ASLR
   • 在分析时尚未找到绕过ASLR的方法

3. Word类型混淆漏洞分析(CVE-2015-1641)

3.1 漏洞环境

• 受影响系统：Windows 7
• 受影响软件：Word 2007
• 分析工具：Windbg、OllyDbg、oletools、notepad++、WinHex
• 样本来源：GitHub公开的漏洞样本

3.2 漏洞原因

Word在解析docx文档的displacedByCustomXML属性时未对customXML对象进行验证，导致可以传入其他标签对象进行处理，造成类型混淆。

3.3 漏洞分析过程

1. 样本分析准备：

   • 解压样本并改后缀名为.doc
   • 使用oletools的rtfobj工具分析，结果显示4个文件
   • 分离保存这些文件用于进一步分析

2. 构造触发文件：

   • 从样本中提取第三个OLE对象
   • 构造为RTF文件
   • 打开该文件时出现错误，故障模块为wwlib.dll

3. 崩溃分析：

   • 异常出现在wwlib模块中的0x5c4a9d30
   • 崩溃指令：mov esi,dword ptr [ecx]
   • 崩溃原因：[ecx]引用到无效地址(ecx=0x7c38bd50)

4. OLE文件分析：

   • 解压OLE文件后，在document.xml中发现：
     • ecx的值是smartTag标签的element属性值
     • displacedByCustomXml属性表示此处要替换为customxml标签
   • 攻击者在smartTag的element中构造了0x7c38bd50

5. 漏洞触发机制：

   • Word解析docx文档时未验证customXML对象
   • 导致可以传入smartTag标签对象
   • 单独加载触发漏洞OLE会引用无效地址

6. 模块依赖：

   • 无效地址位于MSVCR71.DLL模块中
   • 该DLL通过第一个OLE对象"otkloadr.wRAssembly.1"引入

3.4 利用过程分析

1. 完整利用构造：

   • 将第一个OLE对象添加到触发漏洞的OLE前面
   • 构建完整RTF文件运行

2. 条件断点设置：

   • 记录crash时的0x7c38bd50所在模块地址
   • 基于此设置条件断点

3. 地址计算：

   • 0x7C38BD50是smartTag标签的element值
   • 4294960790(0xFFFFE696)是moveFromRangeStart的值
   • 计算得到地址0x7C38BD74

4. 第二次smartTag处理：

   • element值为0x7C38BD68
   • moveFromRangeStart值为0x7C376FC3
   • 计算出地址0x7C38A428
   • 通过memcpy将0x7C376FC3覆盖到0x7C38A428

5. 虚表指针覆盖：

   • 0x7C38A428为虚表指针
   • 覆盖后控制程序执行流

6. ROP链构造：

   • 执行流经过大量地址为0x7c342404的"ret"指令(ret-sled)
   • 随后进入ROP链
   • 最后执行shellcode

7. 堆喷射技术：

   • 在id为1的OLE解压后的activeX1.bin中
   • 包含用于堆喷的数据块
   • nop指令上方是ROP链
   • heapspary前使用大量ret-sled

4. 类型混淆漏洞防护建议

1. 开发层面：

   • 对所有对象类型进行严格验证
   • 使用安全的类型转换方法
   • 实现完整的对象生命周期管理

2. 系统层面：

   • 启用控制流保护(CFG)
   • 启用地址空间布局随机化(ASLR)
   • 使用数据执行保护(DEP)

3. 用户层面：

   • 及时更新软件补丁
   • 不打开来源不明的文档
   • 使用安全软件进行防护

5. 总结

类型混淆漏洞是高级内存破坏漏洞的一种，通过本文分析的两个实例可以看出：

1. IE漏洞(CVE-2017-0037)展示了如何通过HTML和JavaScript操纵对象类型，导致程序错误解析对象。

2. Word漏洞(CVE-2015-1641)则展示了如何通过精心构造的文档格式触发类型混淆，最终实现代码执行。

这两种漏洞都需要深入理解程序的对象处理机制才能发现和利用，防护这类漏洞需要在开发阶段就实施严格的对象类型验证机制。