Windows VistaTop Security Features in Windows Vista

Anthony (A.J.) Smith and Ned Gnichtel

Contents

User Account Control
Internet Explorer Protected Mode
Standard User Support
BitLocker Drive Encryption
Windows Resource Protection
Services Hardening
Advanced Firewall

One of the most common questions customers ask is, "Why should we upgrade to Windows Vista?" There are a lot of reasons to upgrade, but the new security features are among the most significant. Security was a top priority during Windows Vista development, and Microsoft believes the new operating

system is fundamentally more secure than previous versions of Windows®. In this article, we will describe some of the most important security features introduced with Windows Vista®.

User Account Control

From the user perspective, User Account Control (UAC) enables automated elevation request processes, thus notifying users when a program or action requires elevated (administrator) privileges. This solution is far more satisfactory than the "Run As" elevation model present in previous versions of Windows, as it doesn't require that the user know in advance when specific actions or programs require elevated privileges to run correctly.

UAC provides a much safer environment when privileged and non-privileged applications share the same user session and desktop. To achieve this, UAC is built upon a core enabling technology called Mandatory Integrity Control (MIC). MIC implements integrity levels that essentially override the standard Windows NT® discretionary access control model by preventing processes with a lower integrity, such as those of a standard user, from writing to higher-integrity objects and processes that belong to the system or an administrator. This has several important benefits:

• It prevents lower-integrity processes from modify higher-integrity system objects and registry keys.
• It provides a first layer of protection against common shatter attacks, wherein malicious code attempts to use window messages to probe and then implement privilege escalation by having vulnerable, elevated processes run arbitrary code.
• It prevents lower-integrity processes from using window messages to drive the user interface of an elevated process.

UAC uses this functionality to enable a key scenario called Admin Approval Mode (AAM). For home and technical users, AAM is the most common UAC mode, wherein a user logs on interactively with a user account that is a member of the Local Administrators group.

The Logon Security Authentication Subsystem, unlike in previous version of Windows, creates only a standard user security token for the base interactive session when UAC is enabled. When a user needs to run a process, or execute an action, that requires the full admin token, that new process is then instantiated, after the user is prompted via a dialog box shown on the secure desktop (see Figure 1), with a full administrator token.

Figure 1 The user is prompted for administrative credentials when necessary

Without MIC, it would not be possible for UAC to enable the AAM scenario because there would be nothing stopping a process running with the standard user privileges from interacting with the elevated process for the purposes of privilege escalation since both are running with the same user account. This would allow any arbitrary process, such as accidentally executed malware launched by the user, to attack privileged processes.

Even in scenarios where the user is configured to logon as a standard non-privileged user, MIC provides an effective barrier against "shatter" and other user interface attacks for elevated processes that share the session and desktop with non-privileged processes. In Windows XP, unlike in Windows Vista, it is possible for processes running in the user's standard account context to probe other processes, launched with an administrator's elevated privileges via "Run As," in order to attack privileged processes.

It is important to note, however, that for all the sophistication underlying UAC, it is not a true security boundary. UAC, through several well-known mechanisms, can be defeated (though when configured in its most stringent form, UAC attacks are not trivial). But UAC does provide basic impediments to the most common types of privilege-escalation attacks.

Most importantly, with the advent of AAM, by default all Windows applications, unless flagged to request elevation, run with standard user privileges, regardless of administrator group membership or explicitly granted privileges. This is the UAC's most important accomplishment, forcing the Windows application ecosystem to provide applications that run correctly under standard user privileges.

Internet Explorer Protected Mode

Another security technology that takes advantage of MIC is Internet Explorer® 7 Protected Mode, available in Windows Vista. This functionality is implemented by running Internet Explorer, when UAC is enabled, with an integrity level below that of a standard user, significantly reducing the ability of Internet Explorer to modify data or install applications.

As Figure 2 shows, Protected Mode restricts the locations where Internet Explorer can write. By using MIC to effectively sandbox Internet Explorer, it prevents malware profile injection and hijack attacks even if Internet Explorer is compromised.

Figure 2 The two broker processes let Internet Explorer perform elevated operations, as long as the user consents(Click the image for a larger view)

To allow Internet Explorer to function normally, a compatibility layer redirects certain applications to temporary Internet Explorer file locations, which have their directory integrity level set to low. Any attempt to write files or otherwise interact with files and processes running with "Normal" integrity is implemented through a special broker process called IEUSER.EXE. In combination with running with standard user privileges, Internet Explorer Protected Mode provides substantial protection against the newest forms of malware attacks.

Standard User Support

For corporate customers, Windows has historically proven a challenging system to configure for the standard user account context due to application compatibility as well as a number of common user actions that required elevated privileges. To better support the use of standard user accounts, Windows Vista implements two new sets of functionality: Registry & File System Virtualization to better support legacy applications, and new privileges and management functionality.

Because all applications, by default, now run as a standard user, Windows Vista will try to automatically assist applications that attempt to write to admin/system restricted portions of the OS, such as the system portions of the registry and the OS system directories. It does this by redirecting read or writes to these areas to special virtualized locations in the user's local profile. In essence, the application believes it is writing to those sensitive locations, but it is actually writing to the user's profile. This allows most legacy applications to run on Windows Vista successfully without modification.

To further support the standard user scenarios, Windows Vista implements several additional key features. Standard users now can:

• Change the displayed time (not the actual system clock) using the Change the time zone privilege (see Figure 3).
• Configure Wired Equivalent Privacy/Wi-Fi Protected Access (WEP/WPA) settings when they connect to wireless networks (or conversely, profiles for wireless can be centrally managed via Group Policy).
• Change power management settings.
• Install critical Windows updates (or this can be enforced by administrators).
• Install printer and other device drivers approved by IT administrators, as well as ActiveX® control controls from administrator-approved sites, if enabled via Group Policy settings.

Figure 3 Standard users can now change the time zone(Click the image for a larger view)

BitLocker Drive Encryption

BitLocker™ is the Microsoft full volume drive encryption technology that is available with Windows Vista Enterprise and Ultimate editions. With the introduction of SP1, this technology allows for the encryption of multiple volumes on a computer using one or more authentication factors, as Figure 4 shows.

Figure 4 You can encrypt multiple volumes using BitLocker(Click the image for a larger view)

If the system has a trusted platform module (TPM) version 1.2, this component can act as an authentication factor, as can a USB memory stick or a PIN. If a user were to ever lose the USB memory stick or forget the pin, or if a member of the IT department needed access to the machine, a 48-key recovery password can be used to access the volumes. This password can be automatically stored in Active Directory® when BitLocker is enabled for domain-joined computers.

If there's a TPM chip, BitLocker will also check the integrity of the boot configuration data to insure that this data has not been modified or that the drive has not been removed from the machine and installed in another. The encryption used by BitLocker is very secure, with the "AES 128 bit with Diffuser" setting as a default. BitLocker can also be configured to use AES 128, AES 256, and AES 256 with Diffuser via Group Policy.

Windows Resource Protection

Windows Resource Protection (WRP) is a technology that restricts access to certain core system files, folders, and registry keys that are part of the Windows Vista installation. WRP prevents files with .dll, .exe, .ocx, and .sys file extensions from being modified or replaced.

Protecting these key resources is important to overall system stability, and, as such, they can only be modified by the Windows Module Installer service (TrustedInstaller.exe). If someone with administrative rights attempts to modify or replace a file that is protected by WRP, he will be presented with the message shown in Figure 5.

Figure 5 Access to resources is restricted in Windows Vista(Click the image for a larger view)

Services Hardening

Services have been critical to the Windows NT family of operating system for years. While the service model provides important functionality, services have been the target for malicious software attacks because many are network facing and a number of them have historically run the highest privileged account, "LocalSystem." These factors, combined with the fact that services tend to run continuously from startup to shutdown, makes them popular attack targets.

In an effort to make services more secure, Microsoft decided to make some significant changes to how services operate. In particular, services can now run with "least privilege." Instead of having to choose either a high-privilege account, such as LocalSystem, or lower-privilege accounts, such as LocalService and NetworkService, which may not offer adequate functionality, developers can now use any account (including domain and local), and, by specifying the required privileges, the Service Control Manager will remove the unnecessary privileges.

Moreover, Windows Vista adds a number of new, built-in service accounts for granting specific rights to services. These built-in accounts remove, in most cases, the need for domain-wide service accounts, and all password management for the built-in accounts is automatically managed by the OS.

In order to isolate services, developers were given the ability to create a unique service identifier (SID) for their services. Once the SID is created, the developer can set the access control list (ACL) on an object to allow the service access to the object.

To enhance the SID further, developers can also make services more secure by using a write-restricted token to specify that the service can only write to locations it has been given explicit write access to. For example, if a service uses the LocalService account and a unique SID to gain access to "HKLM\Windows\Application X", that service has access to that registry key and to all other objects LocalService has access to. However, if the write-restricted token is added, the service only has access to the Application X registry key and not to any of the other locations LocalService can access.

A final substantial change to the service model in Windows Vista means that all services now run in an isolated Session 0. Historically, Session 0 was shared with the first locally logged on user and thus provided an attack vector to services. With Window Vista, all interactive sessions now run as Session 1 or higher, effectively isolating services from interactive processes.

Advanced Firewall

One of the most important new enterprise features of Windows Vista is the new network stack with its myriad advanced security features. The Firewall and IPsec functionality are now built on a new subsystem called the Windows Filtering Platform (WFP), which provides both the core firewall functionality and is also fully extensible by third parties via a well-documented call-out infrastructure. This allows third parties to provide, for example, application layer filtering as an addition to the existing stateful firewall without having to use unsupported hooking.

Figure 6 shows some of the advanced security that the new Windows Firewall provides. Core features provided in the new Windows Firewall are advanced inbound and outbound configurability, including restrictions based on application path and executable as well as service accounts and groups. Furthermore, connections can be restricted on a per-profile basis and can be subject to Internet Protocol security (IPsec) connection policies. And all of the built-in functionality can now be managed entirely via Group Policy.

Figure 6 Windows Firewall with Advanced Security(Click the image for a larger view)

As you can see, Windows Vista comes with a host of new security features that not only protect against attacks but also limit the damage that attackers can do if they do gain access to a computer. If you were wondering why you should upgrade to Windows Vista, now you know. 

Anthony (A.J.) Smith is a Windows Client Technology Solution Professional with the Microsoft Enterprise and Partner Group (EPG), focusing on Windows Vista deployment and adoption in the New York City area. Prior to joining Microsoft, he spent his career focusing on desktop technology and worked in desktop support, planning, and deployment roles. Anthony is also a regular contributor to the TechNet NY Metro Core Infrastructure Specialist Team Blog at blogs.technet.com/nymciblog.

Ned Gnichtel is an Account Technology Specialist with the Microsoft Enterprise and Partner Group and supports next-generation technology adoption for several of Microsoft’s Fortune 500 and strategic customers. Prior to joining Microsoft, Ned served as the Chief Technologist for distributed systems at a nationwide IT consultancy. Ned’s career has spanned multiple technology disciplines including operating system internals and device driver development, IT infrastructure development, and directory services infrastructure. Ned can be reached for questions at edwingn@microsoft.com.