Logo
programming4us
programming4us
programming4us
programming4us
Home
programming4us
XP
programming4us
Windows Vista
programming4us
Windows 7
programming4us
Windows Azure
programming4us
Windows Server
programming4us
Windows Phone
 
Windows Vista

Security in Windows Vista : Architectural and Internal Windows Vista Security Improvements (part 1)

- Free product key for windows 10
- Free Product Key for Microsoft office 365
- Malwarebytes Premium 3.7.1 Serial Keys (LifeTime) 2019
8/22/2012 3:44:03 PM
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
ImprovementDescription
Code IntegrityDetects malicious modifications to kernel files at startup.
Windows Resource ProtectionPrevents potentially dangerous changes to system resources.
Kernel Patch ProtectionBlocks potentially malicious changes that might compromise the integrity of the kernel on 64-bit systems
Required Driver SigningRequires drivers to be signed, which will improve reliability and make it more difficult to add malicious drivers. Mandatory on 64-bit systems.
Windows Service HardeningAllows system services to access only those resources they normally need to access, reducing the impact of a compromised service.
Authorization ManagerProvides administrators with a tool for configuring which users are allowed to access features of supported .NET Framework applications.
Network Access Protection ClientWhen 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 ManagementReduces risks associated with remote management by supporting encryption and authentication.
Crypto Next Generation servicesAllows the addition of custom cryptographic algorithms to meet government requirements.
Data Execution PreventionReduces the risk of buffer overflow attacks by marking data sections of memory as non-executable.
Address Space Layout RandomizationReduces the risk of buffer overflow attacks by assigning executable code to random memory locations.
New Logon ArchitectureSimplifies development of custom logon mechanisms.
Rights Management Services clientProvides 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 objectsAdministrators 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.

Figure 1. WRP protects critical resources—even if you have administrative credentials—to reduce the risk of software making dangerous changes.


How It Works: Mandatory Integrity Control

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.


Other -----------------
- Adobe Fireworks CS5 : Extra Credit (part 2) - Stroking rendered text
- Adobe Fireworks CS5 : Extra Credit (part 1) - Applying blending modes for image correction
- Adobe Flash Catalyst CS5 : Grouping and transforming
- Adobe Flash Catalyst CS5 : Binding the Data to the Visual Component
- Adobe After Effects CS5 : Building a 3D object (part 2)
- Adobe After Effects CS5 : Building a 3D object (part 1)
- Creating Basic Windows Images : Deploying Custom Images
- Creating Basic Windows Images : Capturing Custom Images
- Adobe Flash Professional CS5 : Importing Graphics - Importing Photoshop and Illustrator Files
- Adobe Flash Professional CS5 : Importing Graphics - Setting Photoshop Import Preferences
 
 
Top 10
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Finding containers and lists in Visio (part 2) - Wireframes,Legends
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Finding containers and lists in Visio (part 1) - Swimlanes
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Formatting and sizing lists
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Adding shapes to lists
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Sizing containers
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 3) - The Other Properties of a Control
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 2) - The Data Properties of a Control
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 1) - The Format Properties of a Control
- Microsoft Access 2010 : Form Properties and Why Should You Use Them - Working with the Properties Window
- Microsoft Visio 2013 : Using the Organization Chart Wizard with new data
 
programming4us
Windows Vista
programming4us
Windows 7
programming4us
Windows Azure
programming4us
Windows Server