Whenever possible, Windows
Vista security features have been designed to be transparent to end
users and to require no administration time. Nonetheless, administrators
and developers can benefit from understanding the architectural
improvements. This section describes these architectural and internal
improvements, as well as improvements that require additional
applications or infrastructure. Table 1 describes these features.
Table 1. Architectural and Internal Windows Vista Security Improvements
| Improvement | Description |
|---|
| Code Integrity | Detects malicious modifications to kernel files at startup. |
| Windows Resource Protection | Prevents potentially dangerous changes to system resources. |
| Kernel Patch Protection | Blocks potentially malicious changes that might compromise the integrity of the kernel on 64-bit systems |
| Required Driver Signing | Requires
drivers to be signed, which will improve reliability and make it more
difficult to add malicious drivers. Mandatory on 64-bit systems. |
| Windows Service Hardening | Allows
system services to access only those resources they normally need to
access, reducing the impact of a compromised service. |
| Authorization Manager | Provides
administrators with a tool for configuring which users are allowed to
access features of supported .NET Framework applications. |
| Network Access Protection Client | When
used together with Windows Server Code Name “Longhorn,” helps to
protect your network from clients who do not meet your security
requirements. |
| Web Services for Management | Reduces risks associated with remote management by supporting encryption and authentication. |
| Crypto Next Generation services | Allows the addition of custom cryptographic algorithms to meet government requirements. |
| Data Execution Prevention | Reduces the risk of buffer overflow attacks by marking data sections of memory as non-executable. |
| Address Space Layout Randomization | Reduces the risk of buffer overflow attacks by assigning executable code to random memory locations. |
| New Logon Architecture | Simplifies development of custom logon mechanisms. |
| Rights Management Services client | Provides
support for opening Rights Management Services protected documents when
the proper applications are installed and the necessary infrastructure
is in place. |
| Multiple local Group Policy objects | Administrators
can apply multiple local Group Policy objects to a single computer,
simplifying security configuration management for workgroup computers. |
The sections that follow describe these features in more detail.
Code Integrity (CI)
When Windows starts up, Code Integrity
(CI) verifies that system files haven’t been maliciously modified and
ensures that there are no unsigned drivers running in kernel mode. The
boot loader checks the integrity of the kernel, the Hardware Abstraction Layer (HAL),
and the boot-start drivers. Once those files are verified, CI verifies
the digital signatures of any binaries that are loaded into the kernel’s
memory space. Additionally, CI verifies binaries loaded into protected
processes and the cryptography DLLs (dynamic-link libraries).
CI works automatically and does not require management.
Note
CI
is an example of a detective countermeasure because it can identify
that the computer was compromised after the fact. While it is always
preferable to prevent attacks, detective countermeasures such as CI
enable you to limit the damage caused by the attack by detecting the
compromise so that you can repair the computer. You should also have a
response plan in place to enable you to quickly repair a system that has
had critical files compromised. |
Windows Resource Protection (WRP)
Any
code that runs in kernel mode, including many types of drivers, can
potentially corrupt kernel data in ways that surface later. Diagnosing
and fixing these bugs can be difficult and time-consuming. Corruption of
the registry tends to have a disproportionate impact on overall
reliability because this corruption can persist across reboots.
Windows Vista
protects system settings from corruption or inadvertent changes that can
cause the system to run incorrectly or to not run at all. Windows
Resource Protection (WRP), the follow-on to the Windows File Protection
(WFP) feature found in previous Windows platforms, sets tight ACLs on
critical system settings, files, and folders to protect them from
changes by any source (including administrators) except a trusted
installer. This prevents users from changing critical system settings
that can render systems inoperable.
Windows Vista also
prevents poorly written drivers from corrupting the registry. This
protection enables the memory-management component to achieve protection
the vast majority of the time, with low overhead. Protected resources
include:
Executable files, libraries, and other critical files installed by Windows
Critical folders
Essential registry keys installed by Windows Vista
WRP will not allow you to modify protected resources, even if you provide administrative credentials. As demonstrated in Figure 1, access will always be denied.
|
One of my favorite new security features in Windows Vista is Mandatory Integrity Control (MIC).
It’s a classical computer science concept from the 1970s that’s finally
getting its first commercial implementation—and of this I’m quite
proud.
While discretionary access control lists (DACLs)
are useful, they have some limitations. They do little to safeguard
system stability and they can’t stop malicious software from tricking
users into executing it. MIC
adds the notion of trustworthiness evaluation into the operating
system. Subjects with low degrees of trustworthiness can’t change data
of higher degrees; subjects with high degrees of trustworthiness can’t
be forced to rely on data of lower degrees. MIC implements an
information flow policy and provides the enforcement mechanism.
When a user logs
on, Windows Vista assigns an integrity token to the user. The token
includes an integrity label that determines the level of access the
token—and therefore the user—can achieve. Securable objects (files,
folders, pipes, processes, threads, window stations, registry keys,
services, printers, shares, interprocess objects, jobs, and directory
objects) also receive an integrity security identifier (SID), which is
stored in the system access control list (SACL) of the object’s security descriptor. The label in the SID specifies the integrity level of the object.
During an access
check, before checking the user’s access through the DACL, Windows Vista
checks the integrity level of the user and compares it to the integrity
level of the requested object. If the user’s level dominates (that is,
is equal to or greater than) the object’s level, the user will be
allowed to write to the object, subject to the DACL, of course. If the
user’s level doesn’t dominate the object’s, the user can’t write to the
object regardless of what the DACL says. Integrity control, therefore,
trumps access lists.
Windows Vista
defines four integrity levels: low, medium, high, and system. Standard
users receive medium; elevated users receive high. Processes that you
start and objects that you create receive your integrity level (medium
or high), or they receive low if the executable file’s level is low;
system services receive system integrity. Objects that lack an integrity
label are treated as medium by the operating system—this prevents low
integrity code from modifying unlabeled objects.
Consider this
scenario: You receive an attachment in an e-mail. When you save the
attachment, it’s written with low integrity because it came from the
Internet—an untrusted source. When you execute the attachment, its
process runs at low integrity because the file object is labeled low;
therefore, your data (labeled medium or high) is protected from
malicious writes by the attachment (although it will be able to read
your data).
Internet
Explorer Protected Mode is built around mandatory integrity control.
Internet Explorer process and extensions run at low integrity and
therefore have write access only to the Temporary Internet Files\Low
folder, History, Cookies, Favorites, and the
HKEY_CURRENT_USER\Software\LowRegistry key. MIC prevents Internet
Explorer from writing anywhere else in the file system or registry—so no
more silent installs of keystroke loggers into your Startup folder. And
because the desktop runs at medium integrity, Internet Explorer can’t
send messages to it—thwarting shatter-style attacks.
Because these new
restrictions might break some applications, a compatibility mode
virtualizes access to medium integrity resources (such as the Documents
folder and the HKEY_CURRENT_USER hive) by redirecting writes to low
integrity locations.
Although it’s completely
invisible, MIC is an important advance in maintaining the security and
stability of Windows Vista. I hope you’ll come to appreciate it as much
as I do.
Steve Riley, Senior Security Strategist
|
Kernel Patch Protection
64-bit versions of Windows Vista, like the 64-bit versions of Windows XP and Windows Server 2003, support Kernel Patch Protection
technology. Kernel Patch Protection prevents unauthorized programs from
patching the Windows kernel, giving you greater control over core
aspects of the system that can affect overall performance, security, and
reliability. Kernel Patch Protection detects changes to critical
portions of kernel memory. If a change is made in an unsupported way
(for example, a user-mode application does not call the proper operating
system functions), Kernel Patch Protection creates a Stop error to halt
the operating system. This prevents kernel-mode drivers from extending
or replacing other kernel services and preventing third-party software
from patching any part of the kernel.
Specifically, to
prevent Kernel Patch Protection from generating a Stop error, 64-bit
drivers must avoid the following practices:
Modifying system service tables
Modifying the interrupt descriptor table (IDT)
Modifying the global descriptor table (GDT)
Using kernel stacks that are not allocated by the kernel
Patching any part of the kernel on AMD64-based systems
In practice, these
factors are primarily significant to driver developers. No 64-bit driver
should ever be released that would cause problems with Kernel Patch
Protection, so administrators should never need to manage or
troubleshoot Kernel Patch Protection.
Note
Kernel
Patch Protection, along with hardware-based Data Execution Prevention
(DEP) and required driver signing, are the key reasons why 64-bit
systems can be more secure than 32-bit systems. |
Required Driver Signing
Drivers
typically run as part of the kernel, which gives them almost
unprotected access to system resources. As a result, drivers that have
bugs or are poorly written, or malware drivers specifically written to
abuse these privileges, can significantly impact a computer’s
reliability and security.
To help reduce the impact
of drivers, Microsoft introduced driver signing beginning with Windows
2000. Signed drivers have a digital signature that indicates they have
been approved by Microsoft and are likely to be free from major
weaknesses that might impact system reliability. Administrators can
configure Windows 2000 and later operating systems to block all unsigned
drivers, which can dramatically decrease the risk of driver-related
problems.
However, the large
number of unsigned 32-bit drivers has made blocking unsigned drivers
impractical for most organizations. As a result, most existing Windows
computers allow unsigned drivers to be installed.
With 64-bit versions
of Windows Vista, all kernel-mode drivers must be digitally signed. A
kernel module that is corrupt or has been subject to tampering will not
load. Any driver that is not properly signed cannot enter the kernel
space and will fail to load. Although a signed driver is not a guarantee
of security, it does help identify and prevent many malicious attacks,
while allowing Microsoft to help developers improve the overall quality
of drivers and reduce the number of driver-related crashes.
Mandatory driver
signing also helps improve the reliability of Windows Vista because many
system crashes result from vulnerabilities in kernel-mode drivers.
Requiring the authors of these drivers to identify themselves makes it
easier for Microsoft to determine the cause of system crashes and work
with the responsible vendor to resolve the issue. System administrators
also benefit from digitally signed and identified drivers because they
get additional visibility into software inventory and install state on
client machines. From a compatibility perspective, existing Windows
Hardware Quality Labs–certified x64 kernel drivers are considered
validly signed in Windows Vista.
Windows Service Hardening
Historically, many
Windows network compromises (especially worms) resulted from attackers
exploiting vulnerabilities in Windows services. Because many Windows
services listen for incoming connections, and often had system-level
privileges, a vulnerability that could allow an attacker to perform
administrative tasks on a remote computer.
Windows Service
Hardening, a new feature in Windows Vista, restricts all Windows
services from performing abnormal activities in the file system,
registry, network, or other resources that could be used to allow
malware to install itself or attack other computers. For example, the
Remote Procedure Call (RPC) service is restricted to performing network
communications on defined ports only, eliminating the possibility of
abusing it to, for instance, replace system files or modify the registry
(which is what the Blaster worm did). Essentially, Windows Service
Hardening enforces the security concept of least privilege on services,
granting them only enough permission to perform their required tasks.
Note
Windows
Service Hardening provides an additional layer of protection for
services based on the security principle of defense in depth. Windows
Service Hardening cannot prevent a vulnerable service from being
compromised—a task Windows Firewall and Automatic Updates supports.
Instead, Windows Service Hardening limits how much damage an attacker
can do in the event the attacker is able to identify and exploit a
vulnerable service. |
Windows Service Hardening reduces the damage potential of a compromised service by:
Introducing a
per-service security identifier (SID) to uniquely identify services,
which subsequently enables access control partitioning through the
existing Windows access control model covering all objects and resource
managers that use ACLs. Services can now apply explicit ACLs to
resources that are private to the service, which prevents other
services, as well as the user, from accessing the resource.
Moving
services from LocalSystem to a lesser-privileged account, such as
LocalService or NetworkService, to reduce the privilege level of the
service.
Stripping unnecessary Windows privileges on a per-service basis—for example, the ability to perform debugging.
Applying
a write-restricted token to services that access a limited set of files
and other resources, so that the service cannot update other aspects of
the system.
Assigning
services a network firewall policy to prevent network access outside
the normal bounds of the service program. The firewall policy is linked
directly to the per-service SID and cannot be overridden or relaxed by
user- or administrator-defined exceptions or rules.
A specific goal of
Windows Service Hardening was to avoid introducing management
complexity for users and system administrators. Every service included
in Windows Vista has been through a rigorous process to define its
Windows Service Hardening profile, which is applied automatically during
Windows Vista installation and requires no ongoing administration,
maintenance, or interaction from the end user. For these reasons, there
is no administrative interface for managing Windows Service Hardening.
Note
Third-party
software developers can also take advantage of the Windows Service
Hardening security benefits by providing profiles for custom services. |
