Microsoft PowerPoint 2010 Heap Overflow

vendor:

PowerPoint

by:

Project Zero

7,8

CVSS

HIGH

Heap Overflow

122

CWE

Product Name: PowerPoint

Affected Version From: Microsoft PowerPoint 2010

Affected Version To: Microsoft PowerPoint 2010

Patch Exists: YES

Related CWE: N/A

CPE: a:microsoft:powerpoint:2010

Metasploit: N/A

Other Scripts: N/A

Tags: N/A

CVSS Metrics: N/A

Nuclei References: N/A

Nuclei Metadata: N/A

Platforms Tested: Windows 7 x86

2016

Microsoft PowerPoint 2010 Heap Overflow

A heap overflow vulnerability was observed in Microsoft PowerPoint 2010 running under Windows 7 x86 with application verifier enabled. The ecx register was pointing to invalid memory in this crash, which 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. The allocation size was 0x20 bytes.

Mitigation:

Ensure that all memory accesses are valid and that all memory allocations are of the correct size.

Source

Exploit-DB raw data:

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=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00210206
ppcore!DllGetLCID+0x18205e:
663088d8 ff7110          push    dword ptr [ecx+10h]  ds:0023:1979aeb0=????????

Call Stack:

ChildEBP RetAddr  Args 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 55              push    ebp
663088d3 8bec            mov     ebp,esp
663088d5 8b4d08          mov     ecx,dword ptr [ebp+8]
663088d8 ff7110          push    dword 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)
1cb7cfa0  00000000 1cb7cfa0 00000002 19045ea0
1cb7cfb0  1979aea0 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=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00210293
ppcore!DllGetLCID+0xd3ae7:
6625a361 8b4870          mov     ecx,dword ptr [eax+70h] ds:0023:00000070=????????

0:000> kb
ChildEBP RetAddr  Args 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