Application Compatibility - Session 0 Isolation

In Windows XP, Windows Server 2003, and earlier versions of the Windows operating system, all services run in the same session as the first user who logs on to the console.  This session is called Session 0. Running services and user applications together in Session 0 poses a security risk because services run at elevated privilege and therefore are targets for malicious agents who are looking for a means to elevate their own privilege level.

The Microsoft Windows Vista operating system mitigates this security risk by isolating services in Session 0 and making Session 0 non-interactive.  In Windows Vista (and Windows Longhorn Server), only system processes and services run in Session 0.  The user logs on to Session 1.  On Windows Longhorn Server, subsequent users log on to subsequent sessions (Session 2, Session 3 etc).  This means that services never run in the same session as users' applications and are therefore protected from attacks that originate in application code.

Specific examples of affected driver classes include:

• Printer drivers, which are loaded by the spooler service
• All drivers authored with the User Mode Driver Framework (UMDF), because these drivers are hosted by a process in Session 0

Application classes affected by this feature:

• Services that create a UI
• A service that tries to use window message functions such as SendMessage and PostMessage to communicate with an application
• Applications creating globally named objects

Sessions in Windows XP / 2003
OK - so we've already mentioned that Session 0 poses a security risk because services run at elevated privilege.  The first user on the console also runs in Session 0 - which provides the most common attack vector used to target unsuspecting users.

Sessions in Windows Vista
In Windows Vista, Session 0 is created for services and user-mode drivers.  Session 1 is created for the first user who logs in.  Applications for this user run in Session 1.

• Each time a user logs in, a session is created for that user
• Each session contains a collection of windows stations
• The only supported interactive window station is WinSta0, so each session gets one of these
• WinSta0 contains the keyboard, mouse, and display device
• Each window station can contain multiple desktops, which have logical display surfaces and can be used to manage windows
• Messages can only be sent between processes that are on the same desktop (the hook procedure of a process can also only receive messages intended for windows created on the same desktop)
• Only one desktop at a time is active
• There are several default desktops – default, WinLogon (secure), and screen-saver

OK - so what could this actually look like in a real world scenario?  Consider the following example - if a service belonging to an application generates a UI element in Session 0 - for example a dialog box waiting for the user to click "OK" or "Cancel", the application is now waiting on the service, and the UI is not displayed in the user session.  From the user perspective, the application appears to be hung, when in actual fact it is performing quite normally, and patiently waiting for a user response that the user cannot see!

As you can imagine - this presents a problem for users, administrators and developers.  However, there are some quick mitigating factors to consider.

• If the application's service uses a UI, a built-in mitigation in Windows Vista allows the user to interact with the Session 0 UI in a special desktop.  This will make the UI specific to the application available and not the entire Session 0 desktop.
• If the application creates globally named objects, then use the Windows XP compatibility mode to ensure that the application will continue to work with the Session 0 services.

When testing applications for compatibility with Windows Vista, consider the following test scenarios:

• Test and verify the application on Windows XP in a Terminal Server mode or a Fast User Switching (FUS) mode.  If the application works properly on Windows XP in these scenarios, then it is very likely to work under Windows Vista.
• Verify that the application functions properly after applying the Window XP compatibility mode, which contains mitigation for some of the Session 0 issues.
• Test the driver in Windows Vista to ensure that it runs properly.  If that is not possible, test the driver in Windows XP with FUS enabled and multiple users logged on.  If the driver works correctly for second and subsequent logged-on users, it is not likely to be affected by the Session 0 changes in Windows Vista.  The only issues that this test does not detect are those related to the absence of the video driver in Session 0 in Windows Vista.

Finally, you can leverage the following Windows Vista capability solutions:

• Use client or server mechanisms such as remote procedure call (RPC) or named pipes to communicate between services and applications.
• Use the WTSSendMessage function to create a simple message box on the user's desktop.  This allows the service to give the user a notification and request a simple response.
• For more complex UI, use the CreateProcessAsUser function to create a process in the user's session.
• Explicitly choose either the Local\ or Global\ namespace for any named objects, such as events or mapped memory, which the service makes available.

And that will do it for a quick look at how Session 0 isolation affects Application Compatibility in Windows Vista.  The links below contain more information on some of the concepts discussed above.  Until next time ...

Additional Resources:

• MSDN - Interactive Services
• Impact of Session 0 Isolation on Services & Drivers in Windows Vista
• Service Changes for Windows Vista
• Test your application with Fast User Switching
• Making a Remote Procedure Call (RPC)
• Client / Server Applications and the WTSSendMessage function
• CreateProcessAsUser function
• Larry Osterman blog post on "Interacting with Services"

 - CC Hameed