User Interface Privilege Isolation - The 'shatter' slayer

In this article/blog we will discuss the User Interface Privilege Isolation control which is a part of the Windows User Account Control set of controls brought in by Windows NT 6.0 i.e. Windows Vista and Windows 2008 Server and the reason it was needed i.e. the Windows ‘Shatter’ attack. We will discuss the Why, What and How of the User Interface Privilege Isolation.

Why we need UIPI – The Windows ‘Shatter’ Attack

Microsoft Windows is an event driven environment, in which processes react to events, the events are set using messages. Different windows in the operating system send each other messages.

Windows is a GUI event driven system. In an event driven system objects can send other objects events. It is possible for non-privileged events to send high-privileged events. There is no check by the system regarding the identity of the process. A process can write a WM_TIMER message to a process, which tells the target process that a kernel timeout has occurred, and this event is set with the name of the function to be called in order to handle the event. The attacker can set the function through the WM_TIMER message. If the attacker is able to put his own malicious code in the memory of the high-privilege application. The attacker achieves this by entering a malicious code code/string like a shell code in the text area which gives input to the high-privileged application, thus the string is now in the memory of the high-privileged application.

In Windows every desktop is fixed to a window station, although there are multiple window stations that handle the display on the monitor and terminal services etc. Of all the window stations Winsta0 is the only one that interacts with the user. Processes can move between window stations, Threads can move between desktops but windows are tied to the window station they started with.

The underlying problem according to Microsoft was that the higher level application should not be run in the same desktop area. The privileges of programs running in one desktop area are similar/same. Microsoft says that “all processes within the interactive desktop are peers”. Or at least they should be peers. Microsoft’s position from the start was very clear that this should not be counted as a design flaw but this is the required environment in which the application needs to function.

What is User Interface Privilege Isolation

Windows User Interface Privilege Isolation (UIPI) is a design change implemented in Windows NT 6.0 (Windows Vista, Windows Server 2008 etc.), which brings together lots of changes including integrity levels for processes.

UIPI is a part of the User Account Control set which isolates high privileged programs from lower-privileged programs. The processes that are using the same interactive desktop cannot send each other messages based on their integrity levels. Thus UIPI prevents the shatter attack.

UIPI works for users who are a member of the local admin group and are running as a standard user, which means that they may have applications of different levels running on the screen.

How does UIPI work

UIPI implements the following principles:

·         A higher-privileged process can send messages to a lower-privileged process but a lower-privileged process cannot send messages to a higher-privileged process.

·         Lower-privilege processes can send high-privilege processes messages if they have been explicitly allowed using the ChangeWindowMessageFilter() function.

·         Lower-level processes can only read from higher-privileged processes.

·        
A program can also bypass the UIPI control if it specifies in its manifest ‘UIaccess’ to ‘true’, this permits the application to bypass the UIPI control only if the following conditions are met:

• The program is installed in the secure locations like %Program files% or %windir%
• The application is signed and trusted by the local computer.

The application being signed is a must. The location constraint can be removed from the User Account Control Group Policy from the setting ‘User Account Control: Only Elevate UIAccess application that are stored in secure locations’, this is set to ‘enabled’ by default. If disabled it will remove the secure installation location and the programs installed outside the secure location can also by pass the UIPI.

·         The following items remained shared between processes at different levels:

• Desktop window, which actually owns the screen surface.
• Desktop heap read-only shared memory
• Global atom table
• Clipboard

·         Technically speaking the lower-privilege  cannot perform the following actions on high-privileged programs

• Monitor a process with journal hooks
• Use SendMessage and PostMessage functions
• Inject DLLs
• Perform Windows handle validation
• Attach to a process using thread hooks

About the Author