Saturday, March 20, 2010

If we could only control that window class...


This is an example of a file run from within a local chm file.
Local chm files are considered as executables.
The following is a research into an interesting bug and NOT a
discussion on a practical security vulnerability.

[OBJECT
id=hh
classid="clsid:adb880a6-d8ff-11cf-9377-00aa003b7a11"
width=100
height=100
]
[PARAM name="Command" value="ShortCut"]
[PARAM name="Button" value="Bitmap:shortcut"]
[PARAM name="Item1" value=",cmd,/c"]
[PARAM name="Item2" value="273,1,1"]
[/OBJECT]

[script]

// The chm loads, executes a process and the process is closed
// The the script clicks the shortcut object after the process has already been closed
// then hh.exe tries to create an error message using a format string (wsprintfA). The error message is:
// "The program specified for the shortcut was started, but the window class "%s" could not be found."
// Then there is an attempt to read from the window class that was assigned to the process executed, which was
// FREEed/destroyed/released when the process was closed. This causes the address that is pulled from the stack to be 3 letters
// from the error message itself and another byte " th\x54"

// an exploitation would require to be able to manipulate the window class
// a proper fix would be one of the following:
// 1) Checking if the window class still exists before using it
// 2) making a copy of the window class upon process creation and using that copy
// 3) removing the format string message

hh.Click();
[/script]

No comments: