How Vista Toughens Services: Overview

Every modern operating system I've ever encountered includes the ability to create and run programs that run unobtrusively in the background performing maintenance functions. Unix and Mac OS (which is really just Unix with a neat UI) call them daemons; in the Windows world we call them services.

Over the years, however, the nature of services has made them the target of computer criminals, and that has made security analysts scrutinize services closely. Unfortunately, although we now know how to harden Windows services against attacks, Windows hasn't made doing that toughening very easy…until now. I think you'll be pleasantly surprised at four changes that Microsoft made to Windows services in Vista-three changes we'll cover in this chapter in detail (and briefly in the last chapter).

Services in Brief

Let's start off with a look at what services are and how they work from a security point of view. Services are basically just regular old Windows programs, but with four differences from regular applications.

First, they can run all of the time. As soon as your computer boots, some services start up and run. (Others can start later-you can control that through Vista's service configuration tools.) They tend to do background sorts of activities, like spooling print jobs to the printer as the Print Spooler service does, or constantly watching your Web surfing so as to warn you of potential spyware, as Windows Defender does, to offer just two examples.

Second, they don't need you logged on to run. If you were running a website on your Vista computer-there was a nice, if limited web server shipped with the Vista betas unless they pulled it when Vista goes gold-then your Vista box could merrily respond to Web requests without your having first to log on and start up its copy of Internet Information Services (IIS). That implies that unlike the programs that I discussed in Chapters 2, 3, and 4, services do not get a copy of your security token and don't run as you; instead, they typically run under one of three accounts known as "service accounts":

LocalSystem An account that used to be called "System" in older Windows and that has nearly all-encompassing local powers and the ability to communicate with other systems over a network.

LocalService An account with very little powers and no ability to network.

NetworkService An account that is basically LocalService with a limited ability to network added.

Third, while services are, again, nothing more than Windows programs, they don't typically start up the way that most Windows programs do. Most programs are invoked by the name of their EXE file-double-click on the Notepad icon and you're really telling Explorer, "load and execute the file notepad.exe." In contrast, services tend not to be directly run but instead run inside a program called a "service host," a program named svchost.exe. Another word for this kind of program is a "wrapper" (although without the gold chains and the tendency to spit into the microphone) and its job is to simplify the process of securing services. Not all of your services, however, live inside the same svchost.exe. You can view your instances of svchost.exe by starting up Task Manager, click the "Show processes from all users" button, then click on the Processes tab, and then the Image Name column to sort the processes by name. You'll see something like Figure 7.1.

Figure 7.1: Svchosts running on a Vista system

As you can see, the Vista system that I'm working on has 13 instances of svchost.exe running. To see the services inside a svchost, use Sysinternals' Process Explorer, which we met back in Chapter 4, to view your processes. Start it up-don't forget to start it elevated by right-clicking its icon and choose Run as administrator-and find a svchost.exe. As you hover your mouse cursor over the svchost.exe, you'll get a tooltip that shows you the services living inside that svchost. Or you can just right-click the svchost, choose Properties and then the Services tab, to see something like Figure 7.2.

Figure 7.2: Services running in a given svchost

I'm taking the time to underscore out how svchosts work to make an important point: services don't get tokens-instances of svchost.exe do. Thus, in Figure 7.2, the five services that you see do not each get their own token filled with SIDs and privileges; instead, that particular instance of svchost.exe gets a token that contains privileges and one or more SIDs, and the five services in svchost.exe that share that token. To see that token, click the Security tab, which shows something like Figure 7.3.

Figure 7.3: The svchost's token displayed in Process Explorer

In that dialog, you can see that this particular svchost.exe runs under NetworkService rather than LocalSystem or LocalService. In the top half of the dialog, Process Explorer lists the SIDs in the token and there are apparently a lot of them, as I'd have to scroll to see them all. The bottom part shows the privileges that this svchost enjoys. Again, the SIDs and privileges on this svchost's token are the only ones that those five services get, and there's no way to give different SIDs and privileges to any one of those services without sharing them with the other four.

The fourth and final aspect of services is that they are programs that everyone loves to worry about. Listen to anyone talk about Windows security (including me), and eventually you'll hear that services are an entry point for bad guys. That's not because services are any more prone to bugs than any other kind of software. Instead, we worry about services because, again, they run all of the time, because many of them communicate over the network, and because many of them run as LocalSystem.

For example, if, say, Calculator possessed some horrible bug that would allow for a buffer overflow exploit that would enable an attacker to take control of your computer, then we wouldn't panic all that much about it because in order to launch that attack, then the attacker would have to be sitting at the computer (because Calc doesn't network) and Calc would have to be running (because you can only exploit a program's bugs when the program's running). In contrast, if, say, the Background Intelligent Transfer Service (BITS) on every Vista box had that horrible bug, then we'd have something to worry about, as BITS runs almost from the moment that you start up a Vista computer, and it has to talk to the network to get your software updates. Furthermore, BITS runs as LocalSystem, which means that if an attacker got control of BITS then he'd be able to do anything to your system that the LocalSystem account can-in other words, anything that he wanted to.