Few could suspect that an innocuous GUI feature such as Windows messages could pose a danger to system security. However, this seemingly innocent mechanism can be used to inject malicious code into another application and escalate an intruder’s privileges.

GUI control and user interaction in Windows is based on events, which represent all supported user actions as well as calls sent between the various components. Event data is exchanged using messages – each event has its corresponding messages and application windows can identify messages and react to them.

A message can therefore contain information about a mouse click or key press, but can also a window refresh request. The whole framework works and does the job it was designed for. Unfortunately, the mechanism was created in times when computer security was not a serious consideration, which can have grave consequences for Windows users today. The two crucial flaws are:

• there is no way to identify the message sender,

• some messages pass pointers to data structures and functions.

When a window receives a message, it has no way identifying the message sender – the messaging API simply provides no such functionality. In practice, this means that a system message is treated on par with a message from an application with the lowest possible privileges. While this is not a problem for a key press message, it becomes much more serious for messages that change application behaviour, for example by modifying its data or function addresses. We will see what opportunities this opens up for intruders, but first let’s have a look at some messaging basics.

How messages are sent

Messages can be sent by calling SendMessage(). Listing 1 shows the function prototype. The first argument is a handle to the window that will receive the message, while the second argument specifies the message type and therefore determines actual function behaviour. The last two parameters can be used to pass extra information, depending on the message type. The function return value also depends on the message type. Table 1 summarises the message types that will be useful for the purpose of this article.

Listing 1. SendMessage() prototype

 
 
LRESULT SendMessage(   HWND hWnd,
UINT Msg,
WPARAM wParam,
LPARAM lParam );

Table 1. Selected message types

Window handle

To send a message, we also need to know the handle for the target window. For the purpose of this article, we will use two functions to obtain the required handle. The first is FindWindow() – Listing 2 presents its prototype.

Listing 2. FindWindow() prototype

 
 
HWND FindWindow(   LPCTSTR lpClassName,
LPCTSTR lpWindowName );

The function goes through all active application windows and returns a handle to the window specified by its parameters – a pointer to the window class name and a pointer to the window title. If NULL is specified as one of the arguments, then only the other argument is used to locate the window. The FindWindow() function is complemented by FindWindowEx(), shown in Listing 3.

A d v e r t i s e m e n t