Security, services and the interactive desktop in Windows


Services in Microsoft Windows are generally console applications that are designed to run unattended. Therefore, services do not typically have a user interface. However, the service may require interaction with the user in some instances.

More Information

Important We strongly recommend that services do not run as interactive services if the services run in an elevated security context such as SYSTEM.

For the Windows user interface, the desktop is the security boundary. Any application that is running on the interactive desktop can interact with any window that is on the interactive desktop, even if that window is not displayed on the desktop. This behavior is true for every application, regardless of the security context of the application that creates the window and regardless of the security context of the application that is running on the desktop. The Windows message system does not allow an application to determine the source of a window message.

Because of these design features, any service that opens a window on the interactive desktop is exposing itself to applications that are executed by the logged-on user. If the service tries to use window messages to control its functionality, the logged-on user can disrupt that functionality by using malicious messages.

It is best that you evaluate for security issues any service that runs as SYSTEM, that supports the interactive desktop by using calls to the OpenWindowStation function and to the GetThreadDesktop function and that creates a user interface.

In Microsoft Windows NT 4.0 and in Microsoft Windows 2000, security restrictions are not fully enforced for accessing the default desktop of an interactive window station. When an application tries to draw a user interface, the security on the window station is not queried for the WINSTA_READSCREEN access right. If the logon security identifier (SID) does not have this access to the window station, a process that is running under that SID should not be able to access the screen contents.

In Microsoft Windows XP, this restriction is correctly enforced. When a process that is running under a logon SID tries to draw to the screen, the GDI subsystem verifies whether the logon token has the WINSTA_READSCREEN access right. If the logon token does not have access, the draw operation is not completed. This behavior causes drawing flaws. You can see these flaws when you run GUI applications by using a token that the LogonUser property has obtained. The LogonUser property is the user name for the currently logged on user.

We recommend that the service writer use a client/server technology such as remote procedure call (RPC), sockets, named pipes or COM to interact with the logged-on user from a service. Additionally, we recommend that you use the MessageBox function together with the MB_SERVICE_NOTIFICATION flag to display simple status messages.

Article ID: 327618 - Last Review: Jun 19, 2014 - Revision: 1