Share via

Interacting with Services

  • Article

In the comments for my first services post, someone asked about the SERVICE_INTERACTIVE_PROCESS flag that can be specified for the CreateService API.

This flag allows the user to specify that the service should be allowed to interact with the logged on user.  The idea of an interactive service was added back in NT 3.1 for components like printer drivers that want to pop up UI.

IMHO this was a spectacularly bad idea that should never have been added to the system.

MSDN has an entire page on interactive services, unfortunately IMHO, it doesn't go into enough detail as to why it's a bad idea to ever specify the SERVICE_INTERACTIVE_PROCESS flag on a service.

The primary reason for this being a bad idea is that interactive services enable a class of threats known as "Shatter" attacks (because they "shatter windows", I believe). 

If you do a search for "shatter attack", you can see some details of how these security threats work.  Microsoft also published KB article 327618 which extends the documentation about interactive services, and Michael Howard wrote an article about interactive services for the MSDN Library.  Initially the shatter attacks went after windows components that had background window message pumps (which have long been fixed), but they've also been used to attack 3rd party services that pop up UI.

The second reason it's a bad idea is that the SERVICE_INTERACTIVE_PROCESS flag simply doesn't work correctly.  The service UI pops up in the system session (normally session 0).  If, on the other hand, the user is running in another session, the user never sees the UI.  There are two main scenarios that have a user connecting in another session - Terminal Services, and Fast User Switching.  TS isn't that common, but in home scenarios where there are multiple people using a single computer, FUS is often enabled (we have 4 people logged in pretty much all the time on the computer in our kitchen, for example).

The third reason that interactive services is a bad idea is that interactive services aren't guaranteed to work with Windows Vista :)  As a part of the security hardening process that went into Windows Vista, interactive users log onto sessions other than the system session - the first interactive user runs in session 1, not session 0.  This has the effect of totally cutting shatter attacks off at the knees - user apps can't interact with high privilege windows running in services. 

 

On the other hand, sometimes it's important to interact with the logged on user.  How do you deal with this problem?  There are a couple of suggestions as to how to resolve the issue.  The first is to use the CreateProcessAsUser API to create a process on the users desktop.  Since the new process is running in the context of the user, privilege elevation attacks don't apply.  Another variant of this solution is to use an existing systray process to communicate with the service.

In addition, if a COM object is marked as running in the security context of the interactive user, it will be activated in the interactive user's session.  You can use a session moniker to start a COM object in a particular session.  There's an example of how to do this here.

Comments

  • Anonymous
    September 14, 2005
    Uh-oh, you called it the "systray". Raymond is going to be mad:

    http://blogs.msdn.com/oldnewthing/archive/2003/09/10/54831.aspx

  • Anonymous
    September 14, 2005
    The comment has been removed

  • Anonymous
    September 14, 2005
    Looking at my system (WinXP SP2, fully patched), I can see several interactive services that came with the OS (seclogon, spooler, schedule, protectedstorage, netman).
    Is there some reason why they were not marked as non interactive in SP2? (I assume that they do not need to open windows on the user desktop, otherwise... it'd be really bad).

  • Anonymous
    September 14, 2005
    What do you think of your Mirra now that Seagate have it?

    I would trust Maxtor or even IBM if I had to but never Seagate! Their drives have failed on me too often.

  • Anonymous
    September 14, 2005
    Larry,

    Thanks for the explanation. :)

    But I'm afraid that do not help much in my situation (I think I should have said more)

    Our company is using a 3rd party FTP server(namely Bulletproof G6 FTP v2.15) which runs as normal application. But then when the logged in user logoff, the application closes and noone can login via FTP.

    The company was pointed to another software (namely FireDaemon v0.07b by Formida) which was free at the time in order to run the application as service. But for reason CreateService() documentation stated, we have to run it as LocalSystem to get it interactive so I can control over varies settings in it's UI. V2.2 start's to run as service itself, but also run in LocalSystem.

    I think the FTP functionality itself won't need LocalSystem privilege to work (consider all those P2P software), it needs to be run at LocalSystem just plainly because that's what it need to become interactive with desktop. I wish to make some small change to get rid of it, but now seems impossible. The CPAU approach won't work because I have no source code... so I really want to have "running as LocalSystem" requirement be workarounded.

  • Anonymous
    September 14, 2005
    i'm a bit ignorant about services, so sorry if this is a stupid question. What, in your opinion, is the best way for a client to talk to a service, i'm thinking mainly about a client on the same machine as the service.
    Would you use COM or sockets or something else?

    thanks.

    bg

  • Anonymous
    September 15, 2005
    BG, check out named pipes for communication with a service.

  • Anonymous
    December 05, 2005
    Any way to get around that Vista console0 issue? I notice you can't even RDP into the console any more.

  • Anonymous
    March 04, 2006
    The comment has been removed

  • Anonymous
    August 04, 2006

    What else has changed with services in Vista?



    The user contexts that services run under has...

  • Anonymous
    September 29, 2006
    What else has changed with services in Vista? The user contexts that services run under has changed dramatically

  • Anonymous
    March 13, 2007
    PingBack from http://winblogs.security-feed.com/2005/09/14/interacting-with-services/

  • Anonymous
    April 27, 2007
    PingBack from http://www.ditii.com/blog/2007/04/27/windows-session-0-isolation/

  • Anonymous
    February 11, 2009
    What else has changed with services in Vista? The user contexts that services run under has changed dramatically

  • Anonymous
    June 08, 2009
    PingBack from http://jointpainreliefs.info/story.php?id=2019