Jump to content

Hacker Technology

A group blog by Leader in Hacker Website - Providing Professional Ethical Hacking Services

  • Entries

    16114

  • Comments

    7952

  • Views

    86383969

Contributors to this blog

  • HireHackking 16114

About this blog

Hacking techniques include penetration testing, network security, reverse cracking, malware analysis, vulnerability exploitation, encryption cracking, social engineering, etc., used to identify and fix security flaws in systems.

HireHackking 
Source: https://code.google.com/p/google-security-research/issues/detail?id=423&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 minimized version of the PoC has three deltas at offsets 0x2404, 0x4041, and 0x8057. OffViz identified these as WordBinaryDocuments[1].WordBinaryDocument[0].stPapxFKPs[23].PAPXFKP[1].rgfc[7].rgfc[1], WordBinaryDocuments[1].WordBinaryDocument[0].stPapxFKPs[23].PAPXFKP[9].rgfc[23].rgfc[16], and WordBinaryDocuments[1].WordBinaryDocument[0].stPapxFKPs[23].PAPXFKP[22].rgbx[11].BXPAP[3].bOffset respectively. 

Attached files:

Fuzzed minimized PoC: 1981563878_min.doc
Fuzzed non-minimized PoC: 1981563878_crash.doc
Original non-fuzzed file: 1981563878_orig.doc
	
DLL Versions:

wwlib.dll: 12.0.6720.5000
mso.dll: 12.0.6721.5000
user32.dll: 5.2.3790.4033

Observed Crash:

eax=17dd0f5b ebx=17dd0f5b ecx=00010100 edx=00010400 esi=00000002 edi=0355d2e8
eip=312ab63d esp=0012dbc0 ebp=0012dbc8 iopl=0         nv up ei pl zr na pe nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00010246

312ab63d ffb0b8000000    push    dword ptr [eax+0B8h] ds:0023:17dd1013=????????
312ab643 ffb0b0000000    push    dword ptr [eax+0B0h]
312ab649 ffb0b4000000    push    dword ptr [eax+0B4h]
312ab64f ffb0ac000000    push    dword ptr [eax+0ACh]
312ab655 ff7518          push    dword ptr [ebp+18h]
312ab658 e8edfcffff      call    wwlib!FMain+0x66d93 (312ab34a)

0:000> kb
ChildEBP RetAddr  Args to Child              
WARNING: Stack unwind information not available. Following frames may be wrong.
0012dbc8 312ab1ff 0355d2e8 0355d2e8 17dd0f5b wwlib!FMain+0x67086
0012dc80 312aad93 0355d2e4 0355d2e8 0355d2e8 wwlib!FMain+0x66c48
0012dcd4 3131b437 0355d2e4 0355d2e8 0012dd1c wwlib!FMain+0x667dc
0012dd30 3131b2e5 2b0127d9 00000000 00000001 wwlib!FMain+0xd6e80
0012e028 31302777 0355d2e4 ffffffff 32123af8 wwlib!FMain+0xd6d2e
0012e130 31304eb5 0155d2e4 00000002 00000000 wwlib!FMain+0xbe1c0
0012e164 3131a5a4 0355d2e4 00000002 0355d2e4 wwlib!FMain+0xc08fe
0012e1bc 312a2780 0355d2e4 00000002 0012e2c0 wwlib!FMain+0xd5fed
0012e248 7739b6e3 030b025a 0000000f 00000000 wwlib!FMain+0x5e1c9
0012e274 7739b874 312a2331 030b025a 0000000f USER32!InternalCallWinProc+0x28
0012e2ec 7739c8b8 00000000 312a2331 030b025a USER32!UserCallWinProcCheckWow+0x151
0012e348 7739c9c6 028c9d38 0000000f 00000000 USER32!DispatchClientMessage+0xd9
0012e370 7c8282f6 0012e388 00000018 0012e4bc USER32!__fnDWORD+0x24
0012e39c 7739cbb2 7739cb75 018e01a2 0000005e ntdll!KiUserCallbackDispatcher+0x2e

In this crash eax is coming from the 3rd argument passed into the function at 0x312ab5e7. It is pointing to valid memory allocated with the following call stack:

0:000> !heap -p -a 0x17dd0f5b
    address 17dd0f5b found in
    _DPH_HEAP_ROOT @ 1151000
    in busy allocation (  DPH_HEAP_BLOCK:         UserAddr         UserSize -         VirtAddr         VirtSize)
                                170a8400:         17dd0f58               a8 -         17dd0000             2000
    7c83d6d4 ntdll!RtlAllocateHeap+0x00000e9f
    0189fd2c vfbasics!AVrfpRtlAllocateHeap+0x000000b1
    33103a8f mso!Ordinal1743+0x00002e07
    329c7e66 mso!MsoPvAllocCore+0x0000005a
    31249eb5 wwlib!FMain+0x000058fe
    312f7a55 wwlib!FMain+0x000b349e
    312f79d2 wwlib!FMain+0x000b341b
    312f727e wwlib!FMain+0x000b2cc7

The indexes being pushed onto the stack eax +0xB8, +0xB0, +0xB4, and +0xAC push the value beyond the allocated size of a8. With pageheap enabled this causes a fault at the first push. This is an exploitable bug because the function at 0x312ab34a uses these values in memory write operations:

0:000> uf 312ab34a
wwlib!FMain+0x66d93:
312ab34a 55              push    ebp
312ab34b 8bec            mov     ebp,esp
312ab34d 8b4508          mov     eax,dword ptr [ebp+8]
312ab350 8b4d0c          mov     ecx,dword ptr [ebp+0Ch]
312ab353 8b5510          mov     edx,dword ptr [ebp+10h]
=> 312ab356 2908            sub     dword ptr [eax],ecx
=> 312ab358 015008          add     dword ptr [eax+8],edx
312ab35b 8b4d14          mov     ecx,dword ptr [ebp+14h]
312ab35e 8b5518          mov     edx,dword ptr [ebp+18h]
=> 312ab361 294804          sub     dword ptr [eax+4],ecx
=> 312ab364 01500c          add     dword ptr [eax+0Ch],edx
312ab367 5d              pop     ebp
312ab368 c21400          ret     14h

At attacker may control these values by grooming memory so that he or she controls the memory after the a8 sized chunk. This can lead to memory corruption and arbitrary code execution. The root cause of this bug suggestive of a type confusion vulnerability earlier in the call stack but this has not been determined with certainty.

Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/37910.zip