Application Security in Windows Vista

Windows Vista changes several things with respect to applications and how they run.. For developers, these changes require rethinking how you write applications. For system administrators, it means rethinking how you use them. This chapter is about how applications work on Windows Vista. Some parts are geared more to developers and some administrators who write their own code. Most of it should be of general interest to administrators who want to know how applications behave differently on Windows Vista. 

Windows Vista makes some very fundamental changes in how applications run on top of it. It is difficult, therefore, to structure a chapter logically that describes it. In some ways, this chapter may seem like a grab bag, and it is. It covers technologies that did not merit their own chapter, but that all are important in their own right.

Client Security

The security of a client (as well as a stand-alone) computer is dependent on a large number of factors. Of course, the security of an individual computer depends for its security on the entities that control that security: the domain controller (DC) and the domain administrators, as well as any local administrators.

In addition, the security of the client depends in large measure on the applications running on that client and how they are running. In this section, we will look at a number of things done to make the clients in your organization not just more secure, but more stable as well. As we all know, you cannot be stable if you are not secure, although you can of course, be secure without being stable.

Service Hardening

It is not just the TrustedInstaller service that can be granted access to objects in that way. Any service, in fact, can have a unique Security Identifier (SID) and can be granted access in the same way. This is part of a technology called "Service Hardening." Service hardening consists of several features.

Service SID

Each service can now, just like the TrustedInstaller, be represented by its own service SID, uniquely identifying that service. This means that you can grant or deny access to any securable object to a specific service. This is a radical departure from previous versions of Windows. In those versions, the service was identified only by the process token of the process within which it ran. That process could contain 10 or 20 services in extreme cases, and every one of those services would have access to all the things that process had access to, as would any service in any other process that was running in the same user context! This made it effectively impossible to restrict access to only an individual service.

Service SIDs change all that. Service SIDs are deterministic and based on the name of a service. That means that if you are writing a service and want to know what name it will have, you can generate the SID before you even start. To see what the SID would be, use the SC command-line tool:

     C:\>sc showsid
     DESCRIPTION:
             Displays the service SID string corresponding to an arbitrary
             name. The name can be that of an existing or non-existent
             service.
     USAGE:
             sc showsid [name]

     C:\>sc showsid foobar

     NAME: foobar
     SERVICE SID: S-1-5-80-3259854826-3107389163-894102390-594757917- 
     2872763584

If you are writing code to find Service SIDs you can find them with LookupAccountName using "NT SERVICE" as the domain and the service name as the account name. However, LookupAccountName will fail unless the service actually exists.

Services Running with Less Privilege

In Windows NT 4.0 and Windows 2000 every built-in service ran as Local-System. In Windows XP, a few ran in the less privileged NetworkService and LocalService accounts. Both of those latter accounts represent the computer, but they have fewer rights than the LocalSystem account. The difference between NetworkService and LocalService is that NetworkService can authenticate to network resources as the computer.

In Windows Vista, many of the services that ran as LocalSystem in Windows XP have been moved to either LocalService or NetworkService. There are 42 services running as LocalService in Windows Vista, compared to 12 in Windows XP; and there are 18 running as NetworkService, compared to 7 in Windows XP. (Note that the exact number of services in each context differs with the version of the OS. These numbers were generated on Windows XP Media Center Edition and Windows Vista Ultimate.) Unfortunately, so many new services have been added that the number of services using LocalSystem is 69 in both cases. Of course, the majority of those services are not actually running in a default installation.

One very interesting example of a service moved to a less privileged context is the Workstation service, which ran as LocalSystem in Windows XP, but as LocalService in Windows Vista.

Reduction of Privileges in Services

In addition to moving services to less privileged context, many of the services also run with restricted tokens that have almost all their privileges removed. For example, the Remote Procedure Call (RPC) Endpoint Mapper service in Windows XP has the following privileges and rights:

• SeAssignPrimaryTokenPrivilege

• SeAuditPrivilege

• SeChangeNotifyPrivilege

• SeCreateGlobalPrivilege

• SeImpersonatePrivilege

• SeIncreaseQuotaPrivilege

• SeShutdownPrivilege

• SeUndockPrivilege

Figure 1 shows a screenshot of the security token on the RPC Endpoint Mapper under Windows Vista.

Figure 1: Security token for RPC Endpoint Mapper on Windows Vista

As you can see from Figure 1, the token for the RPC Endpoint Mapper has only three privileges left in Windows Vista:

• SeChangeNotifyPrivilege

• SeCreateGlobalPrivilege

• SeImpersonatePrivilege

If done properly, this type of service factoring provides significant security benefits. Therefore, we highly encourage everyone to demand the same of Independent Software Vendors (ISV) for services that you purchase. There should be little reason to write services with the high-level privileges we are used to seeing in them. However, nothing will change unless customers demand it. Microsoft cannot make ISVs do the right thing, and we, as authors, can only attempt to shame them. However, if all of us refuse to purchase software that is poorly written and poorly secured, things can change. We encourage you to visit a Web site called Threat Code (http://www.threatcode.com) at some point in your purchasing process. It lists applications that commit egregious security mistakes and can help you avoid spending money on insecurable software. If an application shows up there, we highly recommend you evaluate options rather than reward vendors for not building software that can run securely.

For programmers, the Change/QueryServiceConfig2 Application Programming Interfaces (API) support a new set of flags that allow you to configure the token the service should run as, the privileges it needs, and additional restrictions based on its service SID. One of the restrictions you can configure is to write-restrict its process token.

Write Restricted Tokens

Services can run with a write-restricted token. A write-restricted token can only be used to write objects that grant explicit access to the service SID. Unfortunately, this functionality is not used as much as it potentially could be at the moment. The following 9 of the 150 built-in services use a write-restricted token:

• Base Filtering Engine

• Diagnostic Policy Service

• Net.Msmq Listener Adapter

• Net.Pipe Listener Adapter

• Net.TCP Listener Adapter

• Net.TCP Port Sharing Service

• Performance Logs & Alerts

• Windows Firewall

• Windows Media Center Service Launcher

Firewall Policies Restricting Services

Firewall policies can be configured per user. Because services are now real users, they can be granted, or denied, permission to connect out or accept inbound connections through the firewall as well. This feature, in fact, is what makes it meaningful as a security feature to use outbound filtering on host-based firewalls in Windows Vista.

Named Pipes Hardening

A named pipe is a type of Inter-Process Communications (IPC) mechanism. You can think of a named pipe as a virtual file which allows two processes to hold it open and read and write to it at the same time. A server process that needs data from a client could create a named pipe and then instantiate that pipe to create a pipe instance. A client process that needs to pass data to the server process can then open the named pipe instance and write data to it. The APIs used to read and write named pipes are the same as those used to read and write files, making named pipes a simple and convenient mechanism for IPC.

Named pipes are often used by services to receive data and in those cases, the actual transport used between the server and the client is very often RPC. As part of the general service and RPC hardening that Microsoft has done in Windows Vista, they have also hardened named pipes that use RPC as the transport.

Services often run as individual sub-processes within a larger process. As Figure 2 shows, there could be a large number of services in a single process.

Figure 2: A single service process can host many services.

In Windows XP the Access Control Lists (ACL) on a named pipe created by any of those services granted the right to create pipe instances to the process identity, which is NetworkService in Figure 2. In Windows XP, there was no infrastructure for restricting that right at a more granular level. In Windows Vista, the Service SID is used to allow only the individual service to create named pipe instances. This makes it more complicated for a compromised service from hijacking a named pipe from another service running in the same process. It is not foolproof, but it is one more step toward the end goal of insulating services from failure in other services.

This functionality is also available to third-party services. As mentioned, we highly recommend requesting your ISVs to opt in to using the same functionality.

Windows Resource Protection

Windows Resource Protection (WRP),  is the new name for Windows File Protection (WFP). This name, however, does not really do it justice though. Unlike WFP, which only protected certain files, WRP protects much, much more.

First, almost 70 percent of the files in the Windows directory are now protected by WRP. This is a big improvement over the protection rate of about 12 percent in Windows XP.

Second, WRP protects files primarily using ACLs. Roughly 7,000 files are protected using an ACL Entry (ACE) that allows only the NT SERVICE\ TrustedInstaller service to modify those files. This includes all files with a .dll, .exe, .ocx, .sys, .com, .vbe, and about 50 other extensions that are installed by Windows Vista.

Third, contrary to WFP, WRP protects registry keys in the same way that it protects files-by marking them modifiable only by the TrustedInstaller service.

Finally, WRP uses its cache differently than WFP. In WFP, all protected files are cached in %systemroot%\System32\dllcache. WFP attempts to detect whether a protected file is modified by getting notified of any changes to the files. Upon a change it compares the hash of default data stream in the existing file to its stored value. If the two do not match the existing file is replaced by the copy in the cache directory. A favorite trick by malware was to modify both versions of the file, including the one in the cache directory. WRP, by contrast, does not cache all the files it protects. It caches only those that are needed to start Windows. These files are stored in %systemroot%\winsxs\backup\. This cache directory is considerably smaller than the one on Windows XP because fewer files need to be in there. This reflects an acknowledgement that the primary method for protecting system files need to be built-in security measures, not making two copies of them for malware to modify.

WRP reflects a new way to think about how to stabilize a system. In a way, it is a return to basics, to tried and true security measures, such as ACLs, enabled by new technologies such as service hardening. It also means that developers need to rethink how they use the system. They cannot modify OS files at will. Obviously, an administrator can change the ACL on a protected resource and modify it. However, not only will this generate a UAC prompt, Microsoft is also using the Windows Logo program to prevent legitimate programs from doing so other than through Microsoft-provided redistributable packages. This is designed to prevent ISVs from destabilizing a user's system, as has been done so many times in the past. There are also Application Programming Interfaces (API) that ISVs can use to verify whether a file is protected or not. SfcIsFileProtected and SfcIsKeyProtected, respectively, will return true if a file or registry key is protected. For more information on Windows Resource Protection, see http://www.msdn.microsoft.com/library/en-us/dnlong/html/AppComp.asp?frame=true#appcomp_topic6.

This actually has an important security implication. Previously, it was quite common for ISVs to decompose Microsoft's redistributable packages and install them together with their own applications. In many particularly egregious cases only a portion of the redistributable package was installed. This made servicing of the packages practically impossible. You were no longer using a complete set of Microsoft's components, and if you were, an update installer would likely not recognize that you were and would not be able to patch them. This caused severe grief during several worm outbreaks. For example, one author remembers having a meeting with an ISV over four weeks after SQL Slammer came out. The ISV wanted to know how to patch the version of Microsoft SQL Server Desktop Engine (MSDE) that they had distributed to thousands of customers on five continents. Because they had repackaged the Microsoft package, the Microsoft provided package installers did not work-something which the ISV had only realized after SQL Slam-mer took down their internal test bed. Their software was used to run critical infrastructure, and for all practical purposes, it could not be patched because they had modified Windows system files using a non-approved process.

Clearly, Microsoft keeping a tighter grip on its own components is a boon to stability and serviceability and a benefit to IT Pros everywhere. Not surprisingly, the ISV community is not nearly as enamored with it. Then again, we know that large portions of the ISV community refuse to understand that security is important and is their concern as well.

Session 0 Isolation

Windows Vista includes one particularly fundamental change to how user's applications run, called Session 0 Isolation. To understand this, you first need to understand the concepts of sessions, window stations, and desktops.

Sessions

The easiest way to understand sessions is to consider a terminal server. Each user that logs on to a terminal server gets her own session. This session contains everything that this user sees, including the user's desktops (there may be several) all the windows, and so on. The sessions are numbered from 0 to n. A terminal server supports several interactive sessions. Windows XP supports several, as well, but only under Fast User Switching (FUS). On Windows XP, only one of these can be active at a time.

The first interactive session on Windows XP is created when the system boots. It is called session 0. It is an interactive session and is assigned to the first interactive logon on the system (if FUS is enabled) or the interactive logon (if FUS is not used). In addition, in session 0 you will find all services

Window Stations

Each session contains a collection of Window Stations (winsta). The window stations are essentially containers that hold windows the user sees, the clipboard, and so on. They are also numbered starting at 0. Only WinSta0-the first window station created in each session-can access certain input/output (I/O) devices, such as keyboards, mice, and the screen.

Desktops

Finally, we have desktops, which are logical display surfaces hosting windows, menus, and other objects the user can interact with. A single window station may have several desktops, and a single session may have several window stations. This is depicted in Figure 3.

Figure 3: Sessions can have multiple window stations, which can have multiple desktops.

Why Session Isolation Is Needed

As Figure 3 shows, there is some level of isolation between desktops in the same window station, and between window stations in the same session.

However, as security bulletins MS02-071 (http://www.microsoft.com/technet/security/bulletin/MS02-071.mspx) and MS00-020 (http://www.microsoft.com/technet/security/bulletin/MS00-020.mspx) show, the isolation was insufficient. Mechanisms were found which allowed applications on different desktops in the same window station to communicate with each other. Where those applications were running in different privilege levels this created a local privilege escalation path by means of sending window messages from an unprivileged process to a privileged window on the same desktop or in the same window station. These types of security issues eventually received the name "Shatter attacks," coined by Chris Paget, to denote an attack that "shattered" a window.

Shatter attacks were a problem only if there were privileged applications running on the same desktop as unprivileged applications. Unfortunately, several Windows Services, and literally thousands of third-party services did this. Putting Windows on the interactive desktop was an extremely common way to communicate with the user because it was considerably easier than properly architecting process isolation into a service.

When Microsoft reviewed this type of attack during the design of Windows Vista, it was discovered that it was architecturally impossible to properly isolate high-privileged processes on the same desktop as unprivileged ones. This is where Session 0 isolation came from.

How Session 0 Isolation Works

As mentioned earlier, in Windows XP, all the services run in session 0 along with the interactive user's desktop. In Windows Vista only services run in session 0. Session 0 is also non-interactive. The interactive user's desktop runs in a different session. The first user receives session 1, the second user session 2, and so on.

Session 0 isolation will have a certain application compatibility impact. However, the applications affected by it are primarily services that do things they should not be doing anyway: throw interactive UI on an interactive desktop. One easy way to visualize this problem is with a service that throws up a dialog box on the interactive desktop and then waits for the user to respond to the dialog box. On Windows Vista, this dialog box will never show up and the user will not provide the input. The net result is that the service appears to hang.

There are some ways to mitigate this problem. The best one is for each ISV to redesign their services properly. Instead of having the service throw interactive UI, the service should be split into a service and a user component. The two may communicate via some IPC, such as RPC. This allows the user component to throw UI and get input from the user.

For the individual end user or system administrator, the work-around is not so simple. Some things simply cannot be made to work. For applications with an interactive component, try running the application in Windows XP compatibility mode (set on the property sheet for the exe file) instead. This allows the application to interact with the session 0 desktop. If the application tries to communicate with a service using previously allowed mechanisms, this may allow it to function.

You may also use the Interactive Service Detection Mechanism. This is a service which sits in session 0 and attempts to detect interactive messages and notify the users in other session. A user is then given the option of switching to session 0, where she can respond to the UI, and then switch back to her own desktop. The Interactive Service Detection Mechanism is not started by default, but can be changed to automatic either in the Services snap-in or even using Group Policy if need be. It should be pointed out that any service the Interactive Service Detection Mechanism finds to pop interactive UI is broken by design according to Windows Vista's architecture guidelines. It should be replaced with a properly designed service as soon as such a service is available.

There are additional mitigations for possible application compatibility problems as well. For more information, see http://www.microsoft.com/whdc/system/vista/services.mspx.

Note that session 0 isolation hints at one of the reasons we do not consider UAC to be a security solution. By definition, elevated applications are privileged applications running on the same interactive desktop as unprivileged applications. This makes them potential targets for a privilege escalation attack. Many of the avenues for such attack were closed by Microsoft. However, it is possible, even likely, that some remain. This is why, we recommended not elevating applications within an unprivileged session if at all possible. The safest method still remains to use Fast User Switching (FUS) to log on as a privileged user in a privileged session. This ensures complete separation between elevated and non-elevated applications.

Reducing the Footprint

If there was ever one primary criticism of Windows 2000, it was that it came with everything including the kitchen sink installed by default. Particularly the server versions were provisioned with a lot of things, such as the service that allowed you to publish printers to arbitrary hosts on the Internet via IIS. This became a much worse idea right about the time when a massive buffer overflow vulnerability was found in that service.

To address this issue Microsoft has been refactoring many components to allow certain things to be optional components and also removing things that are rarely used. Some items are gone. For instance, while Windows XP and Windows Server 2003 both shipped with three different versions of Windows Media Player installed by default (5.2, 6.4, and 9.0 on Windows XP and 10.0 on Windows Server 2003); Windows Vista ships with only one (version 11).

What is installed by default, and available for installation, depends on the exact edition of Windows Vista you are using. These comparisons were made using Windows Vista Ultimate and Windows XP Pro Service Pack 2.

We highly recommend that system administrators use what we have here only as a basic overview and evaluate the footprint of their specific installation and what they wish to be part of it.

No Longer Installed by Default

A number of other items we are used to seeing installed by default have also been made optional, as follows:

• Telnet client: The telnet client was not used by the vast majority of users. Therefore, it was made optional.

• Telnet server: The telnet server was installed but not started by default in Windows XP.

• POSIX subsystem: The POSIX subsystem was removed entirely from Windows XP. In Windows 2000, it was installed by default. In Windows Vista, it is part of an optional component called Subsystem for Unix based applications. Making this a separately installable component gives administrators much more control over where it is used.

• TFTP client: The TFTP client was installed by default on every computer running Windows; until Windows Vista came out that is. In Windows Vista, the TFTP client is finally optional.

Gone Altogether

Just like some things are now optional installs, some things are gone altogether, although in some cases they are replaced with other things.

• MSN Explorer: There is apparently no such thing any longer.

• Windows Messenger: Windows Messenger has been deprecated. It is being replaced by Office Live Communicator, while MSN Messenger has been renamed to Windows Live Messenger. This is important for security as many organizations attempt to block messenger services. by blacklisting executables. Naturally, doing so is an ineffective way to control instant messaging traffic.

• NetMeeting: NetMeeting has been on life support, and pretty weak life support at that, for quite a while. In Windows Vista, it has been replaced with Windows Meeting Space. Many of the features are similar to Net-Meeting, including the ability to share the desktop and transfer files. For that reason some organizations will love this feature as an inexpensive collaboration solution, while others will certainly want to prohibit it entirely. If you wish to disable use of Windows Meeting Space you can do so with Group Policy. The settings are under Computer Configuration:Administrative Templates:Windows Components:Windows Meeting Space.

• Hyperterminal: The venerable terminal emulator is now gone. Microsoft never owned the source code for Hyperterminal and when a vulnerability was discovered in it, this became a problem. Probably owing in no small measure to the security bulletin it had to issue for Hyperterminal, Microsoft removed it altogether from Windows Vista. The recommendation is to use the telnet client instead, but that only replaces the telnet functionality in Hyperterminal. Customers in need of a terminal emulator will have to look elsewhere.

Added Instead

There are also some new components installed by default. Some of these were optional in Windows XP, and quite a few others did not exist on Windows XP SP2.

• Windows Fax and Scan service is installed by default on Windows Vista, whereas it was optional on Windows XP SP2.

• Windows Meeting Space is the replacement for NetMeeting.

• Several DVD Player components are included by default in Windows Vista. Windows XP had no built-in support for playing DVDs.

• Tablet PC Optional Components: These are installed on some additions of Windows Vista automatically, whereas they were only present in the Tablet PC Edition of Windows XP.

• Windows Sidebar: This is a new component that puts a strip of components on the right-hand side of the monitor by default. It can be a very interesting productivity tool. However, given that it renders HTML it could conceivably be an attack vector as well. It also runs with medium integrity, contrary to Internet Explorer (IE) itself, which runs with low integrity. At this time we have no indications that this is a problem, but it is something worth paying attention to.

It Should Have Been Gone

It is a bit flippant of us to say that certain things really should have been removed because we, by necessity, do not have access to the usage data that Microsoft does, and when your software is used by 800 million people in everything from fuel pumps to stock brokerage, things change a bit. Nevertheless, there are some things we really wish were gone.

• Debug.exe: The 16-bit debugger is still present on the 32-bit version of Windows. It is not there on the 64-bit version because it does not have a 16-bit subsystem. The theory is that Microsoft's support services use the debugger to troubleshoot problems and it is too much trouble to install it when needed. Instead, everyone gets to have it. A regular user can only debug programs they already own, and of course, they could add a debugger, so there really is no risk from that perspective to having it there. However, if malware manages to run a shell command on a compromised computer, the debugger can be used to transfer files down to the computer with no additional tools installed. Of course, malware can run shell commands a lot of things have already gone wrong, so you need to take the risk with a grain of salt.

• Edlin.exe: We just have to ask: why? What possible use could anyone have for edlin these days? And, if you have no idea what edlin is, it is a line-oriented text editor that originated in the early versions of DOS, before there was Windows, or even edit.exe.

• Edit.exe: While we are on the topic of text editors, it is slightly more likely that someone is going to use edit, but if you are the type to use character based text-editors you would probably just download a Win32 port of vi-the editor of the gods-and not bother with the wysiwyg-wannabe edit.exe. (If you don't know what wysiwyg means, count your blessings.)

• At.exe: Yes, a command line scheduler is needed, but can't we get a command line version of task scheduler instead?

• Finger.exe: Does anyone run fingerd any more?

As we mentioned earlier, the issue of deciding what needs to be included and what can be dropped is very complicated. It spans geopolitical, product marketing, and technical concerns. From that perspective, security is a late entrant to the considerations. We like the fact that Microsoft did remove a few things by default, and we hope it can go further in future versions of Windows. We encourage administrators to look at what they have installed and disable use of features they do not need.