Microsoft Office 2007 – ‘wwlib.dll’ fcPlcfFldMom Uninitialized Heap Usage

  • 作者: Google Security Research
    日期: 2015-08-21
  • 类别:
    平台:
  • 来源:https://www.exploit-db.com/exploits/37909/
  • Source: https://code.google.com/p/google-security-research/issues/detail?id=424&can=1
    
    The following crash was observed in Microsoft Office 2007 with Microsoft Office File Validation Add-In disabled and Application Verifier enabled for testing and reproduction. This bug also reproduced in Office 2010 running on Windows 7 x86. 
    
    The crash is caused by a 1 bit delta from the original file at offset 0x31B. OffViz identified this offset as WordBinaryDocuments[1].WordBinaryDocument[0].WordFIB.FIBTable97.fcPlcfFldMom with an original value of 0x000072C6 and a fuzzed value of 0x00007AC6.
    
    Attached files:
    
    Fuzzed minimized PoC: 2509821532_min.doc
    Fuzzed non-minimized PoC: 2509821532_crash.doc
    Original non-fuzzed file: 2509821532_orig.doc
    	
    DLL Versions:
    
    wwlib.dll: 12.0.6720.5000
    msptls.dll: 12.0.6682.5000
    
    Observed Crash:
    
    eax=00000008 ebx=037bbec4 ecx=0f67df76 edx=c0c0c106 esi=00000000 edi=0012caec
    eip=3124d7d4 esp=0012c9d8 ebp=0012c9e0 iopl=0 nv up ei pl nz na po nc
    cs=001bss=0023ds=0023es=0023fs=003bgs=0000 efl=00210202
    
    3124d7ca 8b4d0cmov ecx,dword ptr [ebp+0Ch]
    3124d7cd 8b5508mov edx,dword ptr [ebp+8]
    3124d7d0 56pushesi
    3124d7d1 57pushedi
    3124d7d2 7214jbwwlib!FMain+0x9231 (3124d7e8)
    => 3124d7d4 8b32mov esi,dword ptr [edx]ds:0023:c0c0c106=????????
    3124d7d6 3b31cmp esi,dword ptr [ecx]
    
    0:000> kb L8
    ChildEBP RetAddrArgs to Child
    WARNING: Stack unwind information not available. Following frames may be wrong.
    0012c9e0 3165adbb c0c0c106 0f67df76 00000008 wwlib!FMain+0x921d
    0012c9f4 6bdd19f7 3211e7e0 c0c0c0c0 0f67df30 wwlib!DllGetLCID+0x1e64e5
    0012caa8 6bdd24c8 0000000f 0012cd90 00127965 MSPTLS!LssbFIsSublineEmpty+0x1f3f
    0012cb28 6bddf8e0 00000000 0012cd90 00000000 MSPTLS!LssbFIsSublineEmpty+0x2a10
    0012cb8c 6bddff5d 037bbec0 00000000 0012cdb4 MSPTLS!LssbFIsSublineEmpty+0xfe28
    0012cbbc 6bddf1ef 00000000 00000000 0ee10fa0 MSPTLS!LssbFIsSublineEmpty+0x104a5
    0012cdc0 6bdc4b85 0304a320 00000bc1 00116333 MSPTLS!LssbFIsSublineEmpty+0xf737
    0012cdf4 312dbeea 0304a320 00000bc1 00116333 MSPTLS!LsCreateLine+0x23
    
    The value in edx is an application verifier canary value for uninitialized heap data. Looking back up the call stack we can see the instruction that pushed this value:
    
    6bdd19de 8d45d0lea eax,[ebp-30h]
    6bdd19e1 50pusheax
    6bdd19e2 ff7704pushdword ptr [edi+4]
    6bdd19e5 8b45f8mov eax,dword ptr [ebp-8]
    => 6bdd19e8 ff704cpushdword ptr [eax+4Ch]
    6bdd19eb 8b45fcmov eax,dword ptr [ebp-4]
    6bdd19ee ff7004pushdword ptr [eax+4]
    6bdd19f1 ff908c000000calldword ptr [eax+8Ch]ds:0023:025ac3ac=3165ada3
    6bdd19f7 3bc6cmp eax,esi
    
    Examining memory at [ebp-8] we see:
    
    0:000> dds poi(ebp-8)-4
    11c22cb411c22d2c # pointer to next heap chunk
    11c22cb84e44534c # tag NDSL (eax points here)
    11c22cbc11c22d30 # flink?
    11c22cc011c22c40 # blink?
    11c22cc400000aea
    11c22cc800000aea
    11c22ccc02642ec4
    11c22cd000000000
    11c22cd400000000
    11c22cd800000aea
    11c22cdc00000000
    11c22ce000000aea
    11c22ce400000000
    11c22ce800000000
    11c22cecc0c0c0c0
    11c22cf0c0c0000d
    11c22cf400001800
    11c22cf800000000
    11c22cfc00001800
    11c22d0000000000
    11c22d04c0c0c0c0 # pushed value (eax+4ch) uninitialized
    11c22d08c0c0c0c0
    11c22d0cc0c0c0c0
    11c22d10c0c0c0c0
    11c22d14c0c0c0c0
    11c22d18c0c0c0c0
    11c22d1cc0c0c0c0
    11c22d20c0c0c0c0
    11c22d24c0c0c0c0
    11c22d28c0c0c0c0
    11c22d2c11c22da4 # start of next heap chunk
    11c22d304e44534c
    
    An attacker may control the uninitialized value by first allocating a heap chunk of the same size such that it will land in the same spot as the above chunk. The attacker can write data to the +4ch offset and then free the chunk back to the system. The attacker will then have control over the pointer in eax+4ch when it is used during . If this points to a valid page it will survive the dereferences in the crashing path. It did not look as though there was an immediately path to cause an out of bounds memory write. However, it is likely that this attacker controlled pointer will need to be free-ed later in execution.
    
    Proof of Concept:
    https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/37909.zip