0day.today - Biggest Exploit Database in the World.
Things you should know about 0day.today:
Administration of this site uses the official contacts. Beware of impostors!
- We use one main domain: http://0day.today
- Most of the materials is completely FREE
- If you want to purchase the exploit / get V.I.P. access or pay for any other service,
you need to buy or earn GOLD
Administration of this site uses the official contacts. Beware of impostors!
We DO NOT use Telegram or any messengers / social networks!
Please, beware of scammers!
Please, beware of scammers!
- Read the [ agreement ]
- Read the [ Submit ] rules
- Visit the [ faq ] page
- [ Register ] profile
- Get [ GOLD ]
- If you want to [ sell ]
- If you want to [ buy ]
- If you lost [ Account ]
- Any questions [ admin@0day.today ]
- Authorisation page
- Registration page
- Restore account page
- FAQ page
- Contacts page
- Publishing rules
- Agreement page
Mail:
Facebook:
Twitter:
Telegram:
We DO NOT use Telegram or any messengers / social networks!
You can contact us by:
Mail:
Facebook:
Twitter:
Telegram:
We DO NOT use Telegram or any messengers / social networks!
Microsoft Office PowerPoint 2010 - Invalid Pointer Reference
Author
Risk
[
Security Risk High
]0day-ID
Category
Date add
CVE
Platform
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://github.com/offensive-security/exploit-database-bin-sploits/raw/master/sploits/40406.zip # 0day.today [2024-11-15] #