0day microsoft html (.chm)

hai dude,i'm an junior high scholl 1st class so,please forgive me if my language acak-acakan malu

From [You must be registered and logged in to see this link.]
"A CHM Help file name has a ".chm" extension. It has a set of web pages
written in a subset of HTML and a hyperlinked table of contents. CHM
format is optimized for reading, as files are heavily indexed. All
files are compressed together with LZX compression. Most CHM browsers
have the capability to display a table of contents outside of the body
text of the Help file."

//////////////\\\\\\\\\\\\\\\\\\\
BUG
\\\\\\\\\\\\\\///////////////////
itss.dll is affected by a stack overflow caused by the copying of an
arbitrary amount of data into a stack buffer during the decompression
of the content.
The following dump comes from the Windows XP 5.2.3790.2847 version:

65E3B12B | 8B87 28010000 MOV EAX,DWORD PTR DS:[EDI+128]
65E3B131 | 0345 0C ADD EAX,DWORD PTR SS:[EBP+C]
65E3B134 | 56 PUSH ESI ; our custom size
65E3B135 | 50 PUSH EAX ; our decompressed
; source
65E3B136 | FF75 08 PUSH DWORD PTR SS:[EBP+8] ; stack destination
65E3B139 | E8 01CDFEFF CALL itss.65E27E3F ; memmove on XP/2003
; memcpy on Windows7

The data that will be copied in this stack buffer is just one of the
decompressed LZX chunks (0x7ffe bytes) of the files embedded in the
input chm.

For reaching the vulnerable code I have modified the two dynamic
numbers after the "/#WINDOWS" tag setting the first to 0 (a value
smaller than the original) and the second to the amount of bytes to
copy, anyway note that the function is used also in other places.

Creating the malformed file from scratch is really a joke:
- get HTML Help Workshop
[You must be registered and logged in to see this link.]
- start HTML Help Workshop, create a new project and choose a name
- enable "HTML Help table of contents (.hhc)" and "HTML files (.htm)"
- select the provided test.hhc and then test.htm
- select the third button "Add/Modify window definitions", give a name
and then OK
- select File->Compile
- open the generated chm file with a hex editor
- search the text /#WINDOWS
- go after the 0x01 byte that follows it and place the bytes 00 ff 7f

I have noticed that it's a bit chaotic to debug this vulnerability
through an user-mode debugger, anyway without it attached the code
execution is correctly reported at the specified address of the
proof-of-concept (0x41414141) and our code is referenced in various
places ([ebp-c], [ebp-4], [ebp+c] and so on).
With the debugger attached is possible to see the new EIP only if it's
higher than 0x7fffffff otherwise it's necessary to guess the correct
16bit canary (destination+0x1c8) and specifying an amount of bytes that
will not be written over the available stack (like 00 83 7f) to see it.

The provided chm_1.chm proof-of-concept contains the address where will
continue the code execution at offset 0x17 of test.gif (set to
0x41414141, you can use any value because it's binary data) and I have
placed a bindshell (w32-bind-ngs-shellcode by SkyLined) at offset 0x200
of the same image file only as reference during my tests.

The folder build_chm_1 instead contains the original files from which
has been created chm_1.chm using the steps listed above.
================================================

correct me if i'm wrong
i'm so sorry just ordinary kid 1st class junior high school at malang city

thanks already share here