扫码分享
验证：
体验盒子Source: https://bugs.chromium.org/p/project-zero/issues/detail?id=866
The following crash was observed in Microsoft PowerPoint 2010 running under Windows 7 x86 with application verifier enabled.
File versions are:
mso.dll: 14.0.7166.5000
ppcore.dll: 14.0.7168.5000
Attached crashing file: 3525170180.ppt
Crashing context:
eax=1979aea0 ebx=1638bb50 ecx=1979aea0 edx=0024e340 esi=00000000 edi=00000000
eip=663088d8 esp=0024e330 ebp=0024e330 iopl=0 nv up ei pl nz na pe nc
cs=001bss=0023ds=0023es=0023fs=003bgs=0000 efl=00210206
ppcore!DllGetLCID+0x18205e:
663088d8 ff7110pushdword ptr [ecx+10h]ds:0023:1979aeb0=????????
Call Stack:
ChildEBP RetAddrArgs to Child
WARNING: Stack unwind information not available. Following frames may be wrong.
0024e330 663088cc 1979aea0 0024e46c 00000000 ppcore!DllGetLCID+0x18205e
0024e350 663072cb 0024e46c e437cde4 00000000 ppcore!DllGetLCID+0x182052
0024e4c8 662fcbda 1cd76fe8 0024e4f0 0024e574 ppcore!DllGetLCID+0x180a51
0024e598 662fc9ee 00000000 0024e5e0 0024e63e ppcore!DllGetLCID+0x176360
0024e5ac 662e82fd 0024e5e0 0024e63e e4362e14 ppcore!DllGetLCID+0x176174
00250738 662e7c88 17802ef8 073def40 1638bb50 ppcore!DllGetLCID+0x161a83
00250774 6619d3e9 002508a4 00250890 1638bb50 ppcore!DllGetLCID+0x16140e
Disassembly:
663088d2 55pushebp
663088d3 8becmov ebp,esp
663088d5 8b4d08mov ecx,dword ptr [ebp+8]
663088d8 ff7110pushdword ptr [ecx+10h]ds:0023:1979aeb0=????????
The ecx register is pointing to invalid memory in this crash. Looking at the call stack and disassembly above we can see that this value was passed in as the first argument to the crashing function. The calling function obtained this value from a pointer in stack memory at 0x0024e46c + 0x10:
0:000> dd poi(0024e46c)
1cb7cfa000000000 1cb7cfa0 00000002 19045ea0
1cb7cfb01979aea0 00000000 00000000 00000000
We can verify that this is allocated memory and find the function that allocated it:
(address changed between runs and is now 0x1cb7cfa0)
0:000> !heap -p -a 1cb7cfa0
address 1cb7cfa0 found in
_DPH_HEAP_ROOT @ 1261000
in busy allocation (DPH_HEAP_BLOCK: UserAddr UserSize - VirtAddr VirtSize)
1d2b14e0: 1cb7cfa0 5c - 1cb7c000 2000
6f748e89 verifier!AVrfDebugPageHeapAllocate+0x00000229
7719616e ntdll!RtlDebugAllocateHeap+0x00000030
7715a08b ntdll!RtlpAllocateHeap+0x000000c4
77125920 ntdll!RtlAllocateHeap+0x0000023a
72eaad1a vrfcore!VerifierSetAPIClassName+0x000000aa
701f16ac vfbasics+0x000116ac
641a6cca mso!Ordinal149+0x000078e0
66118132 ppcore!PPMain+0x00001244
662fcbda ppcore!DllGetLCID+0x00176360
662fc9ee ppcore!DllGetLCID+0x00176174
662e82fd ppcore!DllGetLCID+0x00161a83
Setting breakpoints on ppcore!DllGetLCID+0x00176360 and subsequent memory write access breakpoints at eax+0x10 (there are multiple hits) eventually resulted in the same file crashing with a different context:
eax=00000000 ebx=17c2cb50 ecx=00000000 edx=00000000 esi=1a36eea0 edi=1a36eea0
eip=6625a361 esp=0022e1d0 ebp=0022e1f8 iopl=0 nv up ei ng nz ac po cy
cs=001bss=0023ds=0023es=0023fs=003bgs=0000 efl=00210293
ppcore!DllGetLCID+0xd3ae7:
6625a361 8b4870mov ecx,dword ptr [eax+70h] ds:0023:00000070=????????
0:000> kb
ChildEBP RetAddrArgs to Child
WARNING: Stack unwind information not available. Following frames may be wrong.
0022e1f8 662d7d30 661813c4 ec3f4e62 00000000 ppcore!DllGetLCID+0xd3ae7
0022e220 663088e2 00000000 661813c4 0022e250 ppcore!DllGetLCID+0x1514b6
0022e230 663088cc 1a36eea0 0022e36c 00000000 ppcore!DllGetLCID+0x182068
0022e250 663072cb 0022e36c ec3f4f8a 00000000 ppcore!DllGetLCID+0x182052
0022e3c8 662fcbda 1c7a4fe8 0022e3f0 0022e474 ppcore!DllGetLCID+0x180a
Given the different crashing contexts related to timing when breakpoints are set I suspect this to be a heap corruption bug that Application Verifier does not detect.
Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/40406.zip
体验盒子
