VC ++ enables low-Permission programs in Vista and win7 to send messages to high-Permission programs

Windows 7 has been released, but many programmers have tasted the sweetness of Windows 7 through RTM and other versions. In Windows 7, user interface privilege isolation will be the focus of this article.

We introduced the session 0 isolation of operating system services. Through session 0 isolation, Windows 7 achieves independent and more secure mutual access between sessions, this greatly improves the security of the operating system. After tasting the sweetness of session 0 isolation in the operating system service, the programmers of redmon seem to fall in love with the concept of isolation. Now they introduce the isolation between processes in the same session, bringing about a new user interface privilege isolation.

User Interface privilege isolation

In earlier Windows operating systems, all processes running under the same user have the same security level and have the same permissions. For example, a process can freely send a Windows message to another process window. Since Windows Vista, Windows 7 is also included. For some windows messages, this method will no longer work. A process (or another object) begins to have a new property-privilege level ). A process with a lower privilege level can no longer send messages to a process with a higher privilege level, although they run under the same user permission. This is the so-called User Interface privilege isolation (uipi ).

The biggest purpose of uipi introduction is to prevent malicious code from sending messages to Windows with higher permissions to attack them and obtain higher permissions. This is like a country where everyone is equal. People can exchange greetings to each other. However, there are more bad people. In order to prevent them from committing crimes and obtaining the right they do not deserve, it is artificial to divide each person into different levels, and lower-level users cannot communicate with higher-level users. In human society, this is an annoying hierarchy, but in computer systems, it is a suitable way to maintain system security.

Uipi Operating Mechanism

In Windows 7, when UAC (User Account Control) is enabled, uipi can be run most clearly. In UAC, when an Administrator logs on to the system, the operating system creates two token objects: the first is the administrator token, has most privileges (similar to users in the system before Windows Vista), and the second is a simplified version after filtering, with only the permissions of common users.

By default, processes started with normal user permissions have common privilege levels (uipi levels are classified as low, normal, and high ), system )). For example, you can right-click a process that runs as an administrator or call a process that runs as a ShellExecute by adding the RunAs parameter, such a process has a high level of privilege.

This will cause the system to run two different types of processes with different levels of privileges (of course, technically both processes are under the same user ). You can use the process explorer in the Windows sysinternals tool to view the privilege levels of each process. Http://www.microsoft.com/technet/sysinternals)

Figure 1 process Browser

Displays the same application running at different levels of privileges. The process browser shows that they have different levels of privileges:

Figure 2 same application with different levels of privilege

Therefore, when you find that Windows message communication is faulty between your processes, you can use the process browser to check whether there is a proper level of privilege between the two processes.

Uipi restrictions

As we mentioned above, the classification aims to prevent the following attacks. Therefore, with the user interface privilege isolation, the behavior of an application running at a lower privilege level is subject to many restrictions. It cannot:

Verify the window handle created by a higher-level process

Call sendmessage and postmessage To Send Windows messages to Windows created by higher-level processes

Use thread hooks to process high-privilege Processes

Use setwindowshookex to monitor high-privilege Processes

Execute DLL injection to a high-level process

However, some special windows messages are allowed. Because these messages have little impact on the security of the process. These windows messages include:

0x000-wm_null

0x003-wm_move

0x005-wm_size

0x00d-wm_gettext

0x00e-wm_gettextlength

0x033-wm_gethotkey

0x07f-wm_geticon

0x305-wm_renderformat

0x308-wm_drawclipboard

0x30d-wm_changecbchain

0x31a-wm_themechanged

0x313, 0x31b (WM _???)

Fix uipi Problems

Applications designed based on operating system behaviors before Windows Vista may want Windows messages to be freely transmitted between processes to complete some special work. When these applications run on Windows 7, because of the uipi mechanism, such message transmission is blocked, the application may encounter compatibility problems. To solve this problem, Windows Vista introduces a new API function changewindowmessagefilter. With this function, we can add or delete Windows messages that can be isolated by the privilege level. This is like a process with a higher level of privileges. A filter is set to allow Windows messages that pass through the filter to be added to the filter whitelist, only messages on the whitelist can be transmitted.

If we want to allow a message to be sent to a process with a higher level of privilege, we can call the changewindowmessagefilter function in a process with a higher level of privilege, add the message to the whitelist of the message Filter Using msgflt_add as the parameter. Similarly, we can delete the message from the whitelist using msgflt_remove as the parameter.

In Message 2, system messages are sent and custom messages are sent.

The system message processing is very simple. The process that receives the message needs to add the message to the whitelist, which can be implemented through the following code:

Add the following code at the beginning of the master program to specify what messages are acceptable.

Typedef bool (winapi * _ changewindowmessagefilter) (uint, DWORD );

Bool cvistamsgrecvapp: allowmeesageforvista (uint umessageid, bool ballow) // register the global message of Vista

{

Bool bresult = false;

Hmodule husermod = NULL;

// Vista and later

Husermod = loadlibrary (L "user32.dll ");

If (null = husermod)

{

Return false;

}

_ Changewindowmessagefilter pchangewindowmessagefilter = (_ changewindowmessagefilter) getprocaddress (husermod, "changewindowmessagefilter ");

If (null = pchangewindowmessagefilter)

{

Afxmessagebox (_ T ("create windowmessage filter failed "));

Return false;

}

Bresult = pchangewindowmessagefilter (umessageid, ballow? 1: 2); // msgflt_add: 1, msgflt_remove: 2

If (null! = Husermod)

{

Freelibrary (husermod );

}

Return bresult;

}

For a custom message, it usually refers to a message larger than wm_user. We must first register the message in the system and then call the code above:

# Define wm_mynewmessage (wm_user+ 999)
Uint umsgball =: registerwindowmessage (wm_mynewmessage)

If(! Umsgball)

ReturnFalse;

The registered message is implemented through registerwindowmessage. the parameter of the function is the message value you need to register.

 

At this point, low-level processes can send messages like high-level processes.