This paper presents a new generation of attacks against Microsoft Windows, and possibly other message-based windowing systems. The flaws presented in this paper are, at the time of writing, unfixable. The only reliable solution to these attacks requires functionality that is not present in Windows, as well as efforts on the part of every single Windows software vendor. Microsoft has known about these flaws for some time; when I alerted them to this attack, their response was that they do not class it as a flaw - the email can be found here. This research was sparked by comments made by Microsoft VP Jim Allchin who stated, under oath, that there were flaws in Windows so great that they would threaten national security if the Windows source code were to be disclosed. He mentioned Message Queueing, and immediately regretted it. However, given the quantity of research currently taking place around the world after Mr Allchin's comments, it is about time the white hat community saw what is actually possible.
This paper is a step-by-step walkthrough of how to exploit one example of this class of flaw. Several other attack methods are discussed, although examples are not given. There are many ways to exploit these flaws, and many variations on each of the stages presented. This is just one example.
Background - the Win32 messaging system
Applications within Windows are entirely controlled through the use of messages. When a key is pressed, a message is sent to the current active window which states that a key was pressed. When Windows decides that an application needs to redraw its client area, it send a message to the application. In fact, when any event takes place that an application needs to know about, it is sent a message. These messages are placed into a queue, and are processed in order by the application.
This is a very reliable mechanism for controlling applications. However, on Win32 the mechanism for controlling these messages is flawed. Any application on a given desktop can send a message to any window on the same desktop, regardless of whether or not that window is owned by the sending application, and regardless of whether the target application wants to receive those messages. There is no mechanism for authenticating the source of a message; a message sent from a malicious application is indistinguishable from a message sent by the Windows kernel. It is this lack of authentication that we will be exploiting, taking into consideration that these messages can be used to manipulate windows and the processes that own them.
In this example, I will be exploiting Network Associates VirusScan v4.5.1, running on Windows 2000 Professional. Since the VirusScan Console runs on my desktop as LocalSystem and I am logged on as a guest user, the objective is to trick VirusScan into running my code to elevate my privileges. This is accomplished in several easy stages.
1. Locate a suitable window within VirusScan (an edit box is perfect), and obtain a window handle to it.
2. Remove any length restrictions that may be present on that edit box, so that I can type in an arbitrary quantity of data.
3. Paste in some binary executable code.
4. Force VirusScan to execute my code (as LocalSystem)
This is actually very easy to do. Windows conveniently provides all of the functionality that we will be needing. I have written a small application called Shatter which implements this functionality. You'll also need a hex editor that is capable of copying binary data to the clipboard (I use UltraEdit), and a debugger (I use WinDbg).