zoukankan      html  css  js  c++  java

  • CVE-2017-11882：Microsoft office 公式编辑器 font name 字段栈溢出通杀漏洞调试分析

    x01 漏洞简介

    • 在 2017 年 11 月微软的例行系统补丁发布中，修复了一个 Office 远程代码执行漏洞（缓冲区溢出），编号为 CVE-2017-11882，又称为 “噩梦公式”。该漏洞从修复之日起已经隐藏了 17 年之久，而且通杀目前流行的所有 Office 版本，可见其危害程度。该漏洞位于 Office 的 EQNEDT32.EXE 组件中，该组件的作用是通过 OLE 对象的互操作性协助 Office 软件进行公式的处理，由于在拷贝 Office 传入 font name 字段时没有对该字符串的长度进行限制，所以造成了缓冲区的溢出。攻击者可以利用该漏洞以当前登录的用户身份执行任意命令。
      在这里插入图片描述
    • CVE-2017-11882 漏洞影响的 Office 版本：
      在这里插入图片描述

    x02 测试环境

    注：以上软件有部分是第三方提供的下载支持，如没有进行杀毒处理或者未在虚拟机中安装导致电脑中毒的，后果自负

    x03 RTF 文件中的 OLE 对象互操作性

    1）OLE 对象和 RTF 文件格式介绍

    • OLE 全称 Object Linking and Embedding，及对象的嵌入与链接技术，是 COM 技术的前身。该技术允许在程序之间链接和嵌入对象数据，从而建立复合文档。Office 当中的各种软件都会采用 OLE 技术储存文件规范，通过该规范，一个文件中不仅可以包含文本，而且还可以包括图形、电子表格、甚至是声音视频信息。如下图所示：
      在这里插入图片描述
    • 富文本格式（RTF）规范是为了方便在应用程序之间轻松储存格式化文本和图形的一种编码方法。由 Microsoft 公司制定，它适用于不同的设备、操作环境和操作系统。下图列出了部分 RTF 文档 16 进制内容信息：
      在这里插入图片描述

    2）RTF 中的公式编辑器对象的嵌入

    • 根据 RTF Specification Version 1.7 的文件格式规范，RTF 文件语法格式主要有三类：控制字（如 tf）、控制符（如 ~）和组（ { } ）。而 RTF 中的 OLE 对象主要是通过控制字 object 进行识别，并且在外围包裹着一个完整的组。具体流程如下图所示：
      在这里插入图片描述
    • 插入公式编辑器对象（OLE）。
      在这里插入图片描述
    • 插入完成之后保存。
      在这里插入图片描述
    • 使用 16 进制编辑器打开刚刚插入公式编辑器的 RTF 文档，搜索 object 关键字即可发现插入的对象。
      在这里插入图片描述
    • 下图中的 Equation.3 表示的是公式编辑器对象。插入的对象由 *objclass 引用控制字进行识别。
      在这里插入图片描述

    注：如果想要更详细的了解 RTF 文件中的 OLE 对象的嵌入信息，请参照 RTF 文件规范 v1.7：https://pan.baidu.com/s/11w-xGVoguP-jtpJ6ocpwSA（提取码：9xar）

    3）RTF 中的公式编辑器对象的处理

    • 既然 RTF 文档中可以嵌入公式编辑器对象，那么 Office 是怎么与之进行数据交互的呢？答案是通过 Ole32.dll 和 IPersistStorage 接口实现的，当然了根据情况的不同也可以使用其他接口进行操作。当 Office 读入一个嵌入公式编辑器对象的 RTF 文档时，会调用 Ole32.dll 中的 OleLoad 函数对公式编辑器对象进行初始化。
      在这里插入图片描述
    • 初始化完成之后，继续调用 ole32.dll 中的 CoCreateInstance 函数来初始化公式编辑器对象中的数据。注意这个函数的第一个参数 CLSID，作用是识别 OLE 对象，因为每个 OLE 对象都有自己的 CLSID。到此为止初始化对象就完成了，此时数据会以持久化的方式（序列化）储存。
      在这里插入图片描述
    • 最后公式编辑器组件 EQNEDT32.EXE 调用 IPersistStorage ATL 接口中的 Load 方法就可以对数据进行处理， 也就完成了数据的交互操作。
      在这里插入图片描述
      在这里插入图片描述

    x04 调试分析

    • 使用 Python 脚本制作 POC 样本文件，功能是弹出计算器。
      在这里插入图片描述
      在这里插入图片描述
    • 将 x32dbg 调试器设置为附加调试，注册表路径为 计算机HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindows NTCurrentVersionImage File Execution OptionsEQNEDT32.EXE。
      在这里插入图片描述
    • 打开含有漏洞的文档，断下 WinExec 函数（因为该漏洞文档触发漏洞的方式为使用 WinExec 函数来打开计算器），运行之后成功断在了此函数上。
      在这里插入图片描述
    • 此时栈结构如下图所示，可以看到返回地址已经被覆盖了，因为漏洞模块没有开启任何的安全保护，所以不需要通过 ROP 等方式绕过安全保护。因此栈结构还没有被完全破坏，通过栈向上找出是哪一个函数调用的 WinExec 。
      在这里插入图片描述
    • 如下图所示，eqnedt.4115A7 即为栈中找到的最靠近漏洞触发点的函数。
      在这里插入图片描述
    • 在 eqnedt.4115A7 函数下断，重新运行程序后单步调试，发现到达此位置时函数的返回值会被覆盖，由此确定这个就是漏洞的触发点。
      在这里插入图片描述
    • 运行到函数的返回处。
      在这里插入图片描述
    • 查看此时栈中的数据，发现函数的返回值已经被覆盖为 WinExec 函数的地址。
      在这里插入图片描述
    • 查看 0x0018F354 地址的值，这个也就是让 WinExec 函数执行的命令。
    • 值得注意的是命令和溢出字符是以 0x26 隔开的，成功的避开了空格对拷贝字符的影响；而且 WinExec 函数是 EQNEDT32.EXE 模块本身就有的函数（因为没有 ASLR 保护），并不是从库中调用的。
      在这里插入图片描述
    • 继续 F8 执行下去，运行到了 WinExec 函数的地址，最后会弹出计算器。
      在这里插入图片描述
      在这里插入图片描述
    • 由于 EQNEDT32.EXE 模块是通过 IPersistStorage 接口对 RTF 文档中传入 OLE 的数据进行处理的，所以找到 IPersistStorage::Load 函数分析其处理方式。
    • 因为 IPersistStorage 接口的函数是通过 EQNEDT32.EXE 模块本身调用的，所以并没有相应的符号文件，但是可以从 IPersistStorage 接口的初始化和调用方式推出 IPersistStorage::Load 函数的具体位置。IPersistStorage 接口的初始化如下图所示：
      在这里插入图片描述
      在这里插入图片描述
    • 通过比对后发现 sub_406881 就是我们要找的 IPersistStorage::Load 函数。
      在这里插入图片描述
      在这里插入图片描述
    • 之后通过对比 x32dbg 的调试结果和 IDA 的交叉引用，得出了函数调用链：
      在这里插入图片描述
    • 需要注意的是 sub_406881 和 sub_43B418 这个两个函数。在 sub_406881 中，先调用 GlobalAlloc 函数从堆中分配指定的字节数，然后调用 GlobalLock 函数锁定全局内存对象并返回指向对象内存块第一个字节的指针，指针储存在局部变量 var_3C 中。
      在这里插入图片描述
    • 之后以 eax 为虚函数表的首地址，调用偏移地址为 0x0C 的函数 IUnknown_QueryInterface_Proxy 来获取 MTEF Byte Stream 数据。
      在这里插入图片描述
    • 而获取到的 MTEF Byte Stream 数据就储存在局部变量 var_3C 中，也就是下图中的 [ebp-3C] 中。
      在这里插入图片描述
    • 再来看看 sub_43B418 函数，该函数会通过 sub_4164FA 函数取出 MTEF Byte Stream 中的 font name 字段的数据并且拷贝到局部变量 [ebp-104] 当中。
      在这里插入图片描述
      在这里插入图片描述
    • 样本对照如下：
      在这里插入图片描述
    • 在函数调用链的最后会将 font name 压入，压入参数之后调用漏洞函数 sub_41160F。
      在这里插入图片描述
    • 漏洞函数会将 font name 中的数据拷贝到局部变量 var_28 中。
      在这里插入图片描述
    • 由于并没做任何的判断，并且只要数据的大小超过 0x28，就会造成栈溢出，这也是漏洞产生的根本原因。
      在这里插入图片描述
    • 最后使用带有 mona.py 脚本插件的 Immunity Debugger 查询 EQNEDT32.EXE 模块的安全防护，发现确实没有开启任何防护措施。
      在这里插入图片描述

    x05 补丁修复分析

    • 下载微软安全更新中心关于 CVE-2017-11882 的补丁并打好补丁。这里需要根据 Office 的版本和系统位数自行选择。
      在这里插入图片描述
      在这里插入图片描述
    • 对比之前的未打过补丁的版本，打过补丁的版本对 font name 字符串的长度做了判断，如果长度大于 0x21 的话就将拷贝的长度限制为 0x20，从而达到了防止缓冲区溢出的目的。
      在这里插入图片描述
      在这里插入图片描述

    x06 参考文献

    关于 CVE-2017-11882 漏洞分析到此结束，如有错误，欢迎指正。
  • 相关阅读:
    边界扫描的测试原理及九大指令
    边界扫描(boundary scan)
    setup&hold
    使用InstallShield打包windriver驱动-转
    一个完整的Installshield安装程序实例-转
    高通Trustzone and QSEE介绍
    Linux ALSA声卡驱动之五：移动设备中的ALSA（ASoC）
    Linux驱动中completion接口浅析(wait_for_complete例子，很好)
    dmesg 的时间戳处理
    linux popen函数
  • 原文地址：https://www.cnblogs.com/csnd/p/11800493.html
Copyright © 2011-2022 走看看