####################################################################### Luigi Auriemma Application: Microsoft HTML Help http://www.microsoft.com Versions: <= 6.1 Platforms: Windows (any version included the latest Windows 7) Bug: stack overflow Date: 12 Apr 2011 (found 20 Feb 2011) Author: Luigi Auriemma e-mail: aluigi@autistici.org web: aluigi.org ####################################################################### 1) Introduction 2) Bug 3) The Code 4) Fix ####################################################################### =============== 1) Introduction =============== From http://en.wikipedia.org/wiki/Microsoft_Compiled_HTML_Help: "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." ####################################################################### ====== 2) 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 source (decompressed) 65E3B136 |. FF75 08 PUSH DWORD PTR SS:[EBP+8] ; stack destination 65E3B139 |. E8 01CDFEFF CALL itss.65E27E3F ; memmove or memcpy on Windows 7 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 http://download.microsoft.com/download/0/a/9/0a939ef6-e31c-430f-a3df-dfae7960d564/htmlhelp.exe - 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. ####################################################################### =========== 3) The Code =========== http://aluigi.org/poc/chm_1.zip ####################################################################### ====== 4) Fix ====== No fix. #######################################################################