Application Compatibility - Session 0 Isolation

Application Compatibility - Session 0 Isolation

  • Comments 8
  • Likes

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:

 - CC Hameed

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment
  • PingBack from

  • The Enterprise Platforms Windows Server Perfomance Team have published and explaintion of Session 0.

  • Today we are going to briefly go over the basics of some concepts that can be pretty confusing even at

  • In our previous post on PCA, we discussed several runtime issue detection scenarios. Today, we are going

  • <a href= >portland zip codes</a>

  • Hi.

    I'm having a very strange behavior - CreateProcessAsUser fails with error 233 when called from service while logon screen active. Service

    tries to create a process when new console session connected, so when it receives the SERVICE_CONTROL_SESSIONCHANGE notofication with the WTS_CONSOLE_CONNECT, it obtains a user token (via WTSQueryUserToken or

    OpenProcessToken/DuplicateTokenEx/SetTokenInformation - no sense). In

    most cases it works well, but when it create a process after user

    logoff (and now system in logon screen) it fails with error 233.

    How to reproduce it:

    1. Logon as console user (session 0)

    2. Switch user (logon screen, session 0)

    3. Logon another user (session 1) (CreateProcessAsUser succeeded)

    4. Logoff another user (logon screen, session 2) (CreateProcessAsUser

    fails, 233)

    In my sample i'm trying to launch calc.exe, and in vista it works

    well, problem appears only with the Windows XP.

    Anyone else seen a similar issue, or know why this is happening? If it

    helps, i can upload a sample to reproduce this behavior...


  • I am having the same issue with CreateProcessAsUser at the logon screen (this is to run a vnc server w/o any UI).  WTSQueryUserToken returns a NULL token and CPAU fails.  Any help?

  • I'm old korean. thanks for your punctual explanation. it is helpful!