Saturday 22 July 2006

Avoid interactive services

It’s common, when thinking about providing configuration UI for a Windows service, for the developer to see the ‘Interactive’ checkbox in the service properties dialog. Or, maybe you have a server program which already has UI, which you’d like to turn into a service, and you need that UI to be available to the user.

Don’t be tempted.

Interactive services must run under the SYSTEM account (sometimes shown as LocalSystem). Well, OK, it’s not really a user account (you won’t see it in the user accounts database, it doesn’t have a password, it’s just assigned by the system to the special processes it creates at boot time like CSRSS and WINLOGON) but it behaves a lot like one. Anyway, the point is that it’s very highly privileged, and you should strive to have your services run with only the minimum privileges you need, rather than the maximum available. You cannot create a lower-privileged interactive service.

Interactive services also only work for session 0. On Windows 2000, XP and Server 2003, session 0 is the one which the user logs onto on the physical console – the actual keyboard, mouse and graphics hardware physically plugged into the machine. In Fast User Switching on XP, the first user to log on gets session 0, subsequent users get their own sessions. Windows XP Professional will remote session 0 if the user currently logged on locally to session 0 logs on remotely, or if no user is currently logged on. Windows Server 2003 will only remote session 0 if you pass the /console switch to mstsc.exe (Remote Desktop Connection). Windows 2000 never remotes session 0.

Users with other sessions never see the interactive service UI. If you’re trying to notify an administrator of a problem, they may not see the problem until physically logging on at a console, but the trend is towards remote administration. I have to walk all of probably 20 metres to administer servers at work, but it’s more convenient to do it at my desk, so I use Remote Desktop, when there isn’t a tool I can install on my workstation (for example, I’ve installed the Exchange Server 2003 management tools on my computer, and use RunAs to give myself appropriate privileges when using them).

On the current generation of operating systems, interactive services can be vulnerable to so-called “shatter” attacks, where an attacker sends window messages to the service to cause the service to execute code on his behalf. To mitigate this, Microsoft are making a change for Windows Vista and its successors including the next Windows Server version. Now, no users will log on to session 0 – it will be reserved for privileged processes only. Instead, the first user will log on to session 1. Since processes cannot send window messages across sessions, the shatter attack can no longer work. But this means that now no-one will see your UI. For more information, see the whitepaper “Impact of Session 0 Isolation on Services and Drivers in Windows Vista”.

So what to do? You will have to come up with some method of inter-process communication to allow a separate UI process to send commands to the service and display results. You might as well make it a network-capable IPC mechanism – then you can make your UI process capable of running on another machine.

Sunday 16 July 2006

Warning: Installing VS 6.0 on Vista Beta 2 leaves vulnerable Java VM

I still need to use Visual Studio 6.0 at work – we have a lot of legacy software, and even some actively enhanced software, which uses VB 6.0 and Visual C++ 6.0. The installer for Enterprise Edition requires Microsoft’s Java VM to be installed and won’t continue without it. The version installed dates from 1998 (as does VS 6.0, of course) and is Build 2572.

Windows Update does not offer any updates for this VM on Vista Beta 2. There is no other source of updates. There were many security patches for this software.

When you have finished installing Visual Studio 6.0 you should immediately uninstall the VM.

You should also of course install Visual Studio 6.0 Service Pack 6. Some users have reported problems installing VS6 SP5 but I had no problems with SP6. Well, except that Windows Vista popped up a compatibility box claiming that the software hadn’t installed correctly, but it seemed to be OK.

If you need Java you should install Sun’s runtime environment (at time of writing version 5.0 Update 7). Note that when you have the JRE loaded, the Aero environment will shut down and you’ll revert to the Basic theme – no ‘cool’ 3D or glass effects – until the process that launched Java shuts down. This is because the JRE uses DirectX in an exclusive mode to do its drawing. This is supposed to be fixed by Vista RTM (source).

[Update: I have discovered that you can fake it by simply placing an empty file called msjava.dll in your System32 directory (presumably SysWOW64 on an x64 box). This also works for machines installed from clean with Windows XP Service Pack 2, which doesn’t include the Microsoft VM, although Windows Update does offer updates for the Microsoft VM after installing from the VS 6.0 CD, on XP.]