bugtraq - Stack overflow in Microsoft HTML Help 6.1 (CHM files)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Date: Tue, 12 Apr 2011 15:45:11 +0100
From: Luigi Auriemma <aluigi@...istici.org>
To: bugtraq@...urityfocus.com
Subject: Stack overflow in Microsoft HTML Help 6.1 (CHM files)

#######################################################################

                             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@...istici.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 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
  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.

#######################################################################

--- 
Luigi Auriemma
http://aluigi.org