Application Compatibility - Session 0 Isolation

[CraigMarcho]

First published on TECHNET on Apr 27, 2007
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

[ssubbotin]

Could you please reply to the question posted at https://social.technet.microsoft.com/Forums/en-US/fea1b627-decd-40d7-877b-b34ea5499677/change-screen...

By default session 0 on Windows Server 2016 has non-interactive "screen" resolution 1024x768.
Is it possible to set it to some bigger resolution? How?

Document posted at https://docs.microsoft.com/en-us/previous-versions/windows/hardware/design/dn653293(v=vs.85) mentions display resolution in Session 0 can be 1920x1200.

administrator@EC2AMAZ-MRSO5PP C:\Users\Administrator>setres -i                                       
 1024x768  

administrator@EC2AMAZ-MRSO5PP C:\Users\Administrator> setres -w 1366 -h 768 -f                        
setres will now attempt to apply the following display settings:
  Width:          1366                                                                               
  Height:         768                                                                                
The settings passed in could not be applied to the graphics device.

[gtvmark]

This presents a massive problem for me as I run a large number of render nodes, which I was hoping to administer with PS-remoting. Even though the engine software was running, listening and responding successfully on its network ports, it was only outputting black images.  The rendering engine only has a minimal interface, so I didn't think a disconnected desktop session was a problem until I found out that session 0 also has no access to the GPU. Which the application requires.

I've also encountered a large number of applications which display a status interface although act as a service.  S0I makes these type of applications next to impossible to administer.

This issue was raised with MS shortly after Windows 7 came out but 10 years later the only solution coming out of the rendering forums is "don't use windows"

Has anyone placed any more thought into possible solutions?

[wllenyj]

```

This presents a massive problem for me as I run a large number of render nodes, which I was hoping to administer with PS-remoting. Even though the engine software was running, listening and responding successfully on its network ports, it was only outputting black images.  The rendering engine only has a minimal interface, so I didn't think a disconnected desktop session was a problem until I found out that session 0 also has no access to the GPU. Which the application requires.

I've also encountered a large number of applications which display a status interface although act as a service.  S0I makes these type of applications next to impossible to administer.

This issue was raised with MS shortly after Windows 7 came out but 10 years later the only solution coming out of the rendering forums is "don't use windows"

Has anyone placed any more thought into possible solutions?

```

I am such a user. I can only logon automatically once after each windows instance is started. Do you know how stupid it is?

[ssubbotin]

Hi!

I've found work-around for this issue: you can create an RDP session to windows server specifying virtual resolution it will have, I.E.:

rdesktop -u Administrator -p password -g 1366x768 IP_ADDRESS

Having RDP session created you can run any command in that session with psexec:

psexec -s -i 2 COMMAND

So, the workflow looks like:

• create RDP session while creating a windows instance (anytime), specify resolution you want
• no matter when use psexec (from any service, or ssh, etc) to run command inside that session, it will be attached to virtual screen created for that session

Hope it helps.

[wllenyj]

@ssubbotin Thanks for your comments.

My Windows VM instances are all running on the cloud. And at any time Instances may be scaled up and down. 

It would be great to be able to create interactive sessions inside the windows VM instance itself. Otherwise, I would have to use another process, after the windows VM started, to connect to it remotely, let it trigger a logon for interactive session creation. 

This is really ugly....

Thank you again.