zoukankan      html  css  js  c++  java
  • CVE-2010-3974 Microsoft Windows多个平台Fax Cover Page Editor内存破坏漏洞

            Microsoft Windows Fax Cover Pages用于个性化传真以及呈现更正式外观的传真传输。
            Microsoft Windows XP SP2和SP3,Windows Server 2003 SP2,Windows Vista SP1和SP2,Windows Server 2008 Gold,SP2,R2和R2 SP1,以及Windows 7 Gold和SP1的Fax Cover Page Editor中的fxscover.exe没有正确解析FAX的封面页。远程攻击者可以借助特制.cov文件执行任意代码。

    打开POC文件,异常信息如下

    First chance exceptions are reported before any exception handling.
    This exception may be expected and handled.
    eax=feeefeee ebx=022107a8 ecx=02222dc0 edx=000000c0 esi=02222dc0 edi=00028d30
    eip=6a5cb7af esp=0010f33c ebp=0010f33c iopl=0         nv up ei pl nz na pe nc
    cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00010206
    MFC42u!CObject::IsKindOf+0x7:
    6a5cb7af 8b10            mov     edx,dword ptr [eax]  ds:0023:feeefeee=????????

    这是一个前不着村后不着店的地方,明显不是漏洞触发的第一现场。关闭,启用页堆重新加载,依然是断不到第一现场。这个时候想起了之前看《软件调试》时学到的姿势了,链接在这里http://www.cnblogs.com/Ox9A82/p/5603172.html 果断去掉hpa带上ust和hfc。果然可以想泉哥一样定位到触发点了。crash时情况如下:

    (1d8.ce8): Break instruction exception - code 80000003 (first chance)
    eax=00000000 ebx=00000000 ecx=778b07ed edx=000ef391 esi=00410000 edi=0041d770
    eip=7795280d esp=000ef5e4 ebp=000ef65c iopl=0         nv up ei pl nz na pe nc
    cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00000206
    ntdll!RtlReportCriticalFailure+0x29:
    7795280d cc              int     3

    来看下回溯,如下。一看到ntdll!RtlFreeHeap就知道肯定是hfc起了作用,这个int3 断点也肯定是hfc抛出的(即RtlReportCriticalFailure函数)。

    0:000> kp
    ChildEBP RetAddr  
    000ef65c 7795376b ntdll!RtlReportCriticalFailure+0x29
    000ef66c 7795384b ntdll!RtlpReportHeapFailure+0x21
    000ef6a0 77953ab4 ntdll!RtlpLogHeapFailure+0xa1
    000ef6f8 77917ad7 ntdll!RtlpAnalyzeHeapFailure+0x25b
    000ef7ec 778e2d68 ntdll!RtlpFreeHeap+0xc6
    000ef80c 75f898cd ntdll!RtlFreeHeap+0x142
    000ef858 00a8f43a msvcrt!free+0xcd
    000ef868 00a8ab0c FXSCOVER!CDrawRoundRect::`scalar deleting destructor'+0x1a
    000ef884 00a8b1d4 FXSCOVER!CDrawDoc::Remove+0x96
    000ef890 69c68515 FXSCOVER!CDrawDoc::DeleteContents+0xc
    000ef898 69c684df MFC42u!CDocument::OnNewDocument+0x15
    000ef8a8 00a8a812 MFC42u!COleDocument::OnNewDocument+0xe
    000ef8b0 69c683e8 FXSCOVER!CDrawDoc::OnNewDocument+0xa
    000ef8dc 69c68598 MFC42u!CSingleDocTemplate::OpenDocumentFile+0x103
    000ef96c 00a880fb MFC42u!CDocManager::OnFileNew+0xaa
    000ef978 00a894f3 FXSCOVER!CDrawApp::OnFileNew+0xb
    000ef9c0 00a88f62 FXSCOVER!CDrawApp::OpenDocumentFile+0x57a
    000ef9ec 69c76572 FXSCOVER!CDrawApp::OnFileOpen+0x4a
    000ef9fc 69c5a879 MFC42u!_AfxDispatchCmdMsg+0x49
    000efa30 69c5b957 MFC42u!CCmdTarget::OnCmdMsg+0x13c

    我们看下是不是真的是二次释放,看下free的参数就知道了。怎么看呢?我们知道RtlpFreeHeap是windows native层对free的支持。所以看下哪个参数是一样的就可以知道哪个参数是要释放的堆地址了。果然,0041d788处于一个已释放的堆中,显然这个就是二次释放漏洞了。

    0:000> kv
    ChildEBP RetAddr  Args to Child              
    000ef65c 7795376b c0000374 7796cdc8 000ef6a0 ntdll!RtlReportCriticalFailure+0x29 (FPO: [Non-Fpo])
    000ef66c 7795384b 00000002 76dd4fca 00410000 ntdll!RtlpReportHeapFailure+0x21 (FPO: [Non-Fpo])
    000ef6a0 77953ab4 00000003 00410000 0041d770 ntdll!RtlpLogHeapFailure+0xa1 (FPO: [Non-Fpo])
    000ef6f8 77917ad7 00410000 0041d770 00000000 ntdll!RtlpAnalyzeHeapFailure+0x25b (FPO: [Non-Fpo])
    000ef7ec 778e2d68 0041d770 0041d788 0041d788 ntdll!RtlpFreeHeap+0xc6 (FPO: [Non-Fpo])
    000ef80c 75f898cd 00410000 00000000 0041d788 ntdll!RtlFreeHeap+0x142 (FPO: [Non-Fpo])
    000ef858 00a8f43a 0041d788 0041d788 000ef884 msvcrt!free+0xcd (FPO: [Non-Fpo])
    000ef868 00a8ab0c 00000001 00412e60 031807b8 FXSCOVER!CDrawRoundRect::`scalar deleting destructor'+0x1a (FPO: [Non-Fpo])
    000ef884 00a8b1d4 00000000 031807b8 69c68515 FXSCOVER!CDrawDoc::Remove+0x96 (FPO: [Non-Fpo])
    000ef890 69c68515 031807b8 69c684df 031807b8 FXSCOVER!CDrawDoc::DeleteContents+0xc (FPO: [Non-Fpo])
    000ef898 69c684df 031807b8 031807b8 000ef8dc MFC42u!CDocument::OnNewDocument+0x15 (FPO: [Non-Fpo])
    000ef8a8 00a8a812 031807b8 69c683e8 ee921ffd MFC42u!COleDocument::OnNewDocument+0xe (FPO: [Non-Fpo])
    000ef8b0 69c683e8 ee921ffd 00412e60 00412eec FXSCOVER!CDrawDoc::OnNewDocument+0xa (FPO: [Non-Fpo])
    000ef8dc 69c68598 00000000 00000001 ee921e4d MFC42u!CSingleDocTemplate::OpenDocumentFile+0x103 (FPO: [Non-Fpo])
    000ef96c 00a880fb 031807b8 00aa6000 00a894f3 MFC42u!CDocManager::OnFileNew+0xaa (FPO: [Non-Fpo])
    000ef978 00a894f3 ee915bf0 00000000 00aa8798 FXSCOVER!CDrawApp::OnFileNew+0xb (FPO: [Non-Fpo])
    000ef9c0 00a88f62 00419478 ee915bdc 00000000 FXSCOVER!CDrawApp::OpenDocumentFile+0x57a (FPO: [Non-Fpo])
    000ef9ec 69c76572 00000000 00a81de0 000efa30 FXSCOVER!CDrawApp::OnFileOpen+0x4a (FPO: [Non-Fpo])
    000ef9fc 69c5a879 00aa8798 0000e101 00000000 MFC42u!_AfxDispatchCmdMsg+0x49 (FPO: [Non-Fpo])
    000efa30 69c5b957 0000e101 00000000 00000000 MFC42u!CCmdTarget::OnCmdMsg+0x13c (FPO: [Non-Fpo])
    0:000> !heap -p -a 0041d788 
        address 0041d788 found in
        _HEAP @ 410000
          HEAP_ENTRY Size Prev Flags    UserPtr UserSize - state
            0041d4e0 0101 0000  [00]   0041d4e8    00800 - (free)

     CDrawRoundRect::`scalar deleting destructor'是函数的析构函数,我们可以看到这里的free都是这个析构函数的调用导致的。说明这个堆的二次释放的原因是因为这个CDrawRoundRect对象被释放了两次导致的。

  • 相关阅读:
    程序员移居国外指南(1)-父母怎么办?
    【广州.NET社区线下活动】云定未来
    TDD/BDD和接口、基类、继承、依赖注入DI
    德国慕尼黑.NET俱乐部VS2019发布活动
    大湾区联动:广州深圳助力东莞.NET俱乐部首次线下活动
    .NET的未来-广州.NET俱乐部学生分会
    Belgrade Azure 2019-2-11活动感悟
    参观微软Serbia开发中心和Office365 2019-01-31活动感悟
    MySQL复制(二)--基于二进制日志文件(binlog)配置复制
    MySQL复制(一)--复制概述
  • 原文地址:https://www.cnblogs.com/Ox9A82/p/5718620.html
Copyright © 2011-2022 走看看