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