Microsoft Outlook UAF漏洞分析——CVE-2019-1199

 

 

概述

R.J. Lares®研发团队的McDown(@BeetleChunks)在最新版本的Microsoft Outlook中发现了一个关键的远程代码执行漏洞。目前R.J. Lares R＆D团队已经向微软提交了报告，详细说明了这个问题。该漏洞被命名为CVE-2019-1199，现已针对在Windows 10企业版1809(OS Build 17763.379)上运行的Microsoft Outlook Slow Ring Build版本1902(OS Build 11328.20146)进行了验证。

该漏洞是使用自定义的fuzzer发现的，该fuzz是为了测试使用压缩RTF数据的邮件消息的特定段创建的。经过几次迭代后，团队成员注意到由于对内存中的对象处理不当而导致的几次崩溃。在分析后，证实了这些崩溃是UAF导致的。触发漏洞只需很少的用户交互，因为只要导出Outlook预览窗格就足以触发漏洞，从而导致Outlook立即崩溃。以下GIF描述了成功触发的过程。

 

发现

Outlook支持的消息格式之一.MSG格式符合Microsoft对象(Object)链接(Linking)和嵌入(Embedding)数据结构标准格式(OLE)。OLE结构类似于FAT文件系统，可以很容易使用OffVis来探索。

在探索MSG格式并查询MS-OLEDS文档之后，我们把文件格式中的几个结构确定为模糊测试的最佳候选。使用Python脚本生成测试用例，该脚本利用OLEFILE库读取模板MSG文件，提取特定属性，通过自定义Radamsa Python 包装器运行数据，然后将fuzz测试用例写入磁盘。以下代码段显示了负责创建每个测试用例的函数(fuzz_message_part)。

上面的代码片段在“props_to_fuzz”中提供了一个消息属性列表，然后传递给“fuzz_message_part()”函数。在该函数中，属性将被解析为MSG模板中的位置。然后从这些位置提取数据并通过Radamsa运行以创建新的测试用例。“resolve_property_name()”函数只是将属性类型与将在目标属性上匹配的正则表达式相关联。这显示在以下代码段中。

虽然Radamsa本身就是一个测试用例生成器，但根据我们的经验，使用更有针对性的模糊测试方法可以减少所耗费的时间。

然后将测试用例生成器集成到SkyLined的BugID中，并创建了一个自定义通知系统，该系统将所有新的崩溃数据和分类报告给团队的Slack通道。在完成模糊测试框架的创建之后，团队发现仅在几次迭代后发生了崩溃。

 

崩溃原因分析

在观察到一些有趣的崩溃之后，团队成员使用WinDbg作为主要调试器来开始进行崩溃原因分析。WinDbg附加到Outlook，并在Outlook中打开测试用例，立即导致了内存访问违例。

在选择测试用例后，Outlook预览窗格调用了消息体的解析，导致以下异常(Image Base(基地址)：7ff7c0d00000)：

outlook!StdCoCreateInstance+0x82c0:
7ff7c0e3c100 -> 7ff7c0e3cc24

outlook+0x80850:
7ff7c0d80850 -> 7ff7c0d80e85

outlook+0x81ce0:
7ff7c0d81ce0 -> 7ff7c139a2ab

outlook!HrShowPubCalWizard+0x101b0c:
7ff7c1afe05c -> 7ff7c1afe0d1

outlook!HrShowPubCalWizard+0x101198:
7ff7c1afd6e8 -> 7ff7c1afd7af

outlook!FOutlookIsBooting+0x4620:
7ff7c0e41920 -> 7ff7c0e41b04

outlook!FOutlookIsResuming+0x38200:
7ff7c1021f00 -> 7ff7c1021f68

outlook!FOutlookIsResuming+0x1f6a0:
7ff7c10093a0 -> 7ff7c100942c

outlook+0xafb04:
7ff7c0dafb04 -> 7ff7c0dafb16

outlook!HrGetOABURL+0x77938:
7ff7c1110598 -> 7ff7c1110613 VCRUNTIME140!_CxxThrowException

接下来，在“outlook！StdCoCreateInstance + 0x82c0：7ff7c0e3c100”上设置断点，并继续执行Outlook。在Outlook运行时，Outlook GUI中的另一个组件(例如电子邮件，文件夹，按钮等)被选中。执行此操作后，尝试执行引用未映射内存的地址时发生另一个应用程序异常。

outlook!StdCoCreateInstance+0x82c0:
    7ff7c0e3c100

outlook+0x80850:
    7ff7c0d80850

outlook+0x81ce0:
    7ff7c0d81ce0

outlook+0x7419e:
    7ff7c0d7419e -> crash occurs (test    byte ptr [rcx],1 ds:0000020b`00a76ffc=??)

WinDbg的堆函数用于分析第二个异常时指令指针指向的地址。这表明应用程序在尝试引用处于释放状态的堆块中的数据时崩溃。进一步分析后，证实了的确存在UAF。

0:000> !heap -p -a 20b00a76ffc
    address 0000020b00a76ffc found in
    _DPH_HEAP_ROOT @ 20b17571000
    in free-ed allocation (  DPH_HEAP_BLOCK:         VirtAddr         VirtSize)
                                20b0003c820:      20b00a76000             2000
    00007ff9e51b7608 ntdll!RtlDebugFreeHeap+0x000000000000003c
    00007ff9e515dd5e ntdll!RtlpFreeHeap+0x000000000009975e
    00007ff9e50c286e ntdll!RtlFreeHeap+0x00000000000003ee
    00007ff9ad247f23 mso20win32client!Ordinal668+0x0000000000000363
    00007ff9ad1a2905 mso20win32client!Ordinal1110+0x0000000000000065
    00007ff7c0d74a55 outlook+0x0000000000074a55
    00007ff7c0d7449f outlook+0x000000000007449f
    00007ff7c0dbe227 outlook+0x00000000000be227
    00007ff7c0dbcdaf outlook+0x00000000000bcdaf
    00007ff7c0dbb9e0 outlook+0x00000000000bb9e0
    00007ff7c12db320 outlook!HrGetCacheSetupProgressObject+0x0000000000008740
    00007ff7c0da75e7 outlook+0x00000000000a75e7
    00007ff7c0da7373 outlook+0x00000000000a7373
    00007ff7c0eaae24 outlook!RefreshOutlookETWLoggingState+0x0000000000023694
    00007ff7c0eaa525 outlook!RefreshOutlookETWLoggingState+0x0000000000022d95
    00007ff7c0d6d946 outlook+0x000000000006d946
    00007ff7c0d6d2d4 outlook+0x000000000006d2d4
    00007ff9e2d5ca66 USER32!UserCallWinProcCheckWow+0x0000000000000266
    00007ff9e2d5c34b USER32!CallWindowProcW+0x000000000000008b
    00007ff9d55ab0da Comctl32!CallNextSubclassProc+0x000000000000009a
    00007ff9d55aade8 Comctl32!TTSubclassProc+0x00000000000000b8
    00007ff9d55ab0da Comctl32!CallNextSubclassProc+0x000000000000009a
    00007ff9d55aaef2 Comctl32!MasterSubclassProc+0x00000000000000a2
    00007ff9e2d5ca66 USER32!UserCallWinProcCheckWow+0x0000000000000266
    00007ff9e2d5c582 USER32!DispatchMessageWorker+0x00000000000001b2
    00007ff7c0dd9a10 outlook+0x00000000000d9a10
    00007ff7c1051b85 outlook!IsOutlookOutsideWinMain+0x0000000000005545
    00007ff7c0f104e7 outlook!HrBgScheduleRepairApp+0x000000000004a4d7
    00007ff7c105b646 outlook!OlkGetResourceHandle+0x00000000000045d6
    00007ff9e4b981f4 KERNEL32!BaseThreadInitThunk+0x0000000000000014
    00007ff9e511a251 ntdll!RtlUserThreadStart+0x0000000000000021

 

总结

利用此漏洞需要用户使用受影响的Microsoft Outlook软件版本打开特制文件。在电子邮件攻击情形中，攻击者可以通过将特制文件发送给用户并诱导用户打开该文件来利用此漏洞。在基于Web的攻击情形中，攻击者可以托管网站(或利用一个可接受托管用户提供内容的受感染网站)，在其中包含利用此漏洞的特制文件。攻击者无法强迫用户访问该网站。相反，攻击者必须说服用户点击链接，通常是通过电子邮件或即时消息中的诱导，然后诱使他们打开特制文件。

Microsoft在2019年8月的更新中附带了此漏洞的补丁，你可能需要尽快更新你的系统。