Tech·Ed 2006

Kernel Patch Protection aka "PatchGuard"

Scott Dorman — Mon, 30 Oct 2006 21:06:00 GMT

If anyone has been following this technology closely, there have been a lot of complaints by some of the security vendors regarding PatchGuard. I first heard about this technology at TechEd 2006 in a lot of the Vista sessions.

The recent controversy caused me to do a little more research in to this technology and the issues surrounding it.

The official name for this technology is called Kernel Patch Protection (KPP) and it's purpose is to increase the security and stability of the Windows kernel. KPP was first supported in Windows Server 2003 SP1, Windows XP, and Windows XP Professional Edition. The important thing to understand about this support is that it is for x64 architectures only.

KPP is a direct outgrowth of both customer complaints regarding the security and stability of the Windows kernel and Microsoft's Trustworthy Computing initiative, announced in early 2002.

In order to understand the controversy surrounding KPP, it is important to understand what KPP actually is and what aspects of the Windows operating system it deals with.

What is the Kernel?

The kernel is the "heart" of the operating system and is one of the first pieces of code to load when the operating system starts. Everything in Windows (and almost any operating system, for that matter) runs on a layer that sits on top of the kernel. This makes the kernel the primary factor in the performance, reliability and security of the entire operating system.

Since all other programs and many portions of the operating system itself depend on the kernel, any problems in the kernel can make those programs crash or behave in unexpected ways. The "Blue Screen of Death" (BSoD) in Windows is the result of an error in the kernel or a kernel mode driver that is so severe that the system can't recover.

What is Kernel Patching?

According to Microsoft's KPP FAQ, kernel patching (also known as kernel "hooking") is

the practice of using internal system calls and other unsupported mechanisms to modify or replace code or critical structures in the kernel of the Microsoft Windows operating system with unknown code or data. "Unknown code or data" is any code or data that is not provided by Microsoft as part of the Windows kernel.

What exactly, does that mean? The most common scenario is for programs to patch the kernel by changing a function pointer in the system service table (SST). The SST is an array of function pointers to in-memory system services. For example, if the function pointer to the NtCreateProcess method is changed, anytime the service dispatch invokes NtCreateProcess, it is actually running the third-party code instead of the kernel code. While the third-party code might be attempting to provide a valid extension to the kernel functionality, it could also be malicious.

Even though almost all of the Windows kernels have allowed kernel patching, it has always been an officially unsupported activity.

Kernel patching breaks the integrity of the Windows kernel and can introduce problems in three critical areas:

Reliability
Since patching replaces kernel code with third-party code, this code can be untested. There is no way for the kernel to assess the quality of intent of this new code. Beyond that, kernel code is very complex, so bugs of any sort can have a significant impact on system stability.
Performance
The overall performance of the operating system is largely determined by the performance of the kernel. Poorly designed third-party code can cause significant performance issues and can make performance unpredictable.
Security
Since patching replaces known kernel code with potentially unknown third-party code, the intent of that third-party code is also unknown. This becomes a potential attack surface for malicious code.

Why Kernel Patch Protection?

As I mentioned earlier, the primary purpose of KPP is to protect the integrity of the kernel and improve the reliability, performance, and security of the Windows operating systems. This is becoming increasingly more important with the prevalence of malicious software that is implementing "root kits". A root kit is a specific type of malicious software (although it is usually included as a part of another, larger, piece of software) that uses a variety of techniques to gain access to a computer. Increasingly, root kits are becoming more sophisticated and are attacking the kernel itself. If the rootkit can gain access to the kernel, it can actually hide itself from the file system and even from any anti-malware tools. Root kits are typically used by malicious software, however, they have also been used by large legitimate businesses, including Sony.

While KPP is a good first step at preventing such attacks, it is not a "magic bullet". It does eliminate one way to attack the system...patching kernel images to manipulate kernel functionality. KPP takes the approach that there is no reliable way for the operating system to distinguish between "known good" and "known bad" components, so it prevents anything from patching the kernel. The only official way to disable KPP is by attaching a kernel debugger to the system.

KPP monitors certain key resources used by the kernel to determine if they have been modified. If the operating system detects that one of these resources has been modified it generates a "bug check", which is essentially a BSoD, and shuts down the system. Currently the following actions trigger this behavior:

Modifying system service tables.
Modifying the interpret 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. This is currently detected only on AMD64-based systems.

Why x64?

At this point, you may begin to wonder why Microsoft chose to implement this on x64 based systems only. Microsoft is again responding to customer complaints in this decision. Implementing KPP will almost certainly impact comparability of many legitimate software, primarily security software such as anti-virus and anti-malware tools, which were built using unsupported kernel patching techniques. This would cause a huge impact on the consumer and also on Microsoft's partners. Since x64-based machines still make up the smaller install base (although they are gaining ground rapidly) and the majority of x64-based software has been rewritten to take advantage of the newer architecture, the impact is considered to be substantially smaller.

So...why the controversy?

Since KPP prevents an application or driver from modifying the kernel, it will, effectively, prevent that application or driver from running. KPP in Vista x64 requires any application drivers be digitally signed, although there are some non-intuitive ways to turn that off. (Turning off signed drivers does prevent certain other aspects of Windows from operating, such as being able to view DRM protected media.) However, all that really means is anyone with a legitimately created company and about $500 per year to spend can get the required digital signature from VeriSign. Unfortunately, even it is a reputable company, it still doesn't provide any guarantees as to the reliability, performance, and security of the kernel.

In order for software (or drivers) to work properly on an operating system that implements KPP, the software must use Microsoft-documented interfaces. If what you are trying to do doesn't have such an interface, then you cannot safely use that functionality. This is what has lead to the controversy. The security vendors are saying that the interfaces they require are not publicly documented by Microsoft (or not yet at any rate) but that Microsoft's own security offerings (Windows OneCare, Windows Defender, and Windows Firewall) are able to work properly and use undocumented interfaces. The security vendors want to "level the playing field".

There are many arguments on both sides of the issue, but it seems that many of them are not thought out completely. Symantec and McAfee have argued that the legitimate security vendors be granted exceptions to KPP using some sort of signing process. (See the TechWeb article.) However, this is fraught with potential problems. As I mentioned earlier, there is currently no reliable way to verify that code is actually from a "known good" source. The closest we can come to that is by digital signing, however, a piece of malicious code can simply include enough pieces from a legitimate "known good" source and hook into the exception.

So lets say, for arguments sake, that Microsoft does relent and is able to come up with some sort of exception mechanism that minimizes (or even removes) the chance of abuse. What happens next? Windows Vista, in particular, already includes an array of new features to provide security vendors ways to work within the KPP guidelines.

The Windows Filtering Platform (WFP) is one such example. WFP enables software to perform network related activities, such as packet inspection and other firewall type activities. In addition to WFP, Vista implements an entirely new TCP stack. This new stack has some fundamentally different behavior than the existing TCP stack on Windows. We also have network cards that implement hardware based stacks to perform what is called "chimney offload", which effectively bypasses large portions of the software based TCP stack. Hooking the network related kernel functions (as a lot of software based firewalls currently do), will miss all of the traffic on a chimney offload based network card. However, hooking in to WFP will catch that traffic.

Should Microsoft stop making technological innovations in the Windows kernel simply because there are a handful of partners and other ISVs that are complaining? The important thing to realize is that KPP is not new in Windows Vista. It has been around since Windows XP 64-bit edition was released. Why is it now that the security vendors are realizing that their products don't work properly on the x64-based operating systems? The main point Microsoft is trying to get across is that most of the functionality required doesn't have to be done in the kernel. Microsoft has been working for the last few years trying to assist their security partners in making their solutions compatible. If there is an interface that isn't documented, or functionality that a vendor believes can only be accomplished by patching the kernel, they can contact their Microsoft representative or email msra@microsoft.com for help finding a documented alternative. According to the KPP FAQ, "if no documented alternative exists...the functionality will not be supported on the relevant Windows operating system version(s) that include patch protection support."

I think the larger controversy is the fact that there are now documented ways to break KPP. This is where Microsoft and it's security partners and other security ISVs should be spending their time and energy. If we are going to have a reliable and secure kernel, we need to focus on locking down the kernel so that no one is able to breach it, including the hackers. This is an almost endless process, as the attackers generally have almost infinite amounts of time to bring their "products" to market and don't really have an quality issues to worry about. Even with the recent introduction by Intel and AMD of hardware based virtualation technology (which essentially creates a virtual mini-core processor that can run a specially created operating system), there is still a long way to go.

What's next?

While it is important to understand the goals of KPP and the potential avenues of attack against it, the most important thing for the security community to focus on is in making sure that the Windows kernel stays safe. The best way to do this is to keep shrinking the attack surface until it is almost non-existent. There will always be an attack surface, however, the smaller that surface becomes the easier it is to protect. Imagine guarding a vault. If there is only one way in and out, and that entrance is only 2-feet wide it is much more easily guarded than a vault that has 2 entrances, each of which are 30-feet wide.

However, as malware technology advances it is important for the security technology that tries to protect against it to advance as well. In fact, the security technology really needs to be ahead of the malware if it is to be successful. PatchGuard has already been hacked, some of the proposed Microsoft APIs for KPP won't be available until sometime in 2008, and the security vendors do have legitimate reasons for needing to access certain portions of the kernel.

Host Intrusion Prevention Systems (HIPS), for instance, uses kernel access to prevent certain types of attacks, such has buffer overflow attacks or process injection attacks, by watching for system functions being called from memory locations where they shouldn't be called. The Code Red Worm would not have been detected if only file-based protection systems were in use.

The bottom line is that the malware vendors are unpredictable and not bound by any legal, moral, or ethical constraints. They are also not bound by customer reviews, deadlines, and code quality. The security vendors and Microsoft need to work together to ensure that the attack surface for the kernel and Windows itself is small and stays small. They can do this by:

Establishing a more reliable way to authenticate security vendors and their products that will prevent "spoofing" by the malware vendors.
Minimizing the attack surface of the Windows Kernel.
Establishing documented APIs to interact with the kernel to perform security related functions, such as firewall activities.
Enforcing driver signatures...in other words, don't allow this mechanism to be turned off. At least don't allow it to be turned off for certain security critical drivers.
Enforcing security software digital signatures. If you want your security tool to run, it must be signed. Again, don't allow this mechanism to be turned off.
Establishing a more secure way for the security products to hook in to the kernel.
Restricting products to patching only specific areas of the kernel. Currently, it is possible to patch almost any portion of the kernel.
Enforcing Windows certification testing for any security products.

Tech·Ed 2006 Webcast series, update

Scott Dorman — Thu, 13 Jul 2006 10:11:00 GMT

For those of you who attended Tech·Ed 2006, the recorded sessions will be available on CommNet for on-demand viewing by July 21st. The DVD should be received by August 15 and shipped to the address you provided during registration. The DVD's will contain the PowerPoint presentations and recorded sessions.

BitLocker™ - The dirty details

Scott Dorman — Tue, 04 Jul 2006 13:21:00 GMT

One of the new security features coming in Windows Vista and Longhorn is the new BitLocker™ Drive Encryption technology. BitLocker™ is designed to help prevent information loss, whether it is by theft or accidental. Information loss is costly to business on several levels, and the U.S. Department of Justice estimates that intellectual property theft cost enterprises $250 billion in 2004.

BitLocker™ Drive Encryption gives you improved data protection on your notebooks, desktops, and servers by providing a transparent user experience that requires little to no interaction on a protected system. BitLocker also prevents the use of another operating system or hacking tool to break file and system protections by preventing the offline viewing of user data and OS files through enhanced data protection and boot validation using TPM v1.2.

For those of you who may not know, TPM stands for Trusted Platform Module. So what's that? TPM is a piece of hardware that is part of the motherboard that:

Performs cryptographic functions
- RSA, SHA-1, RNG
- Meets encryption export requirements
Can create, store, and manage keys
- Provides a unique Endorsement Key (EK)
- Provides a unique Storage Root Key (SRK)
Performs digital signature operations
Holds platform measurements (hashes)
Anchors a chain of trust for keys and credentials
Protects itself against attacks

So now that you know what a TPM is, why should you use one? A TPM is a hardware implementation of a Root-of-Trust, which can be certified to be tamper resistant. When combined with software, it can protect root secrets better than software alone. A TPM can ensure that keys and secrets are only available for use when the environment is appropriate.

The important thing to know about BitLocker is that it will only encrypt the Windows partition. You also won't be able to dual-boot another operating system on the same partition, different partitions are fine. Any attempts to modify the protected Windows partition will render it unbootable.

To completely protect all of the data on the computer, you will need to use a combination of BitLocker on the Windows partition and Encrypted File System (EFS) on the other partitions. When properly configured, EFS is computationally infeasible to crack.

Even with all of the new security that is provided by BitLocker, it can't stop everything. Some of the areas that BitLocker is helpless to defend against are:

Hardware debuggers
Online attacks—BitLocker is concerned only with the system’s startup process
Post logon attacks
Sabotage by administrators
Poor security maintenance
BIOS reflashing
- Protection against this can be enabled if you wish

Additional Resources

Tech·Ed 2006 Webcast series

Scott Dorman — Wed, 28 Jun 2006 21:05:00 GMT

For those of you who didn't get to go to Tech·Ed this year, Microsoft has made some of the webcasts and breakout sessions available free. It isn't everything that was presented at the conference, but it's what Microsoft considers the best (or most popular) topics. Unfortunately, for those of who did attend, the presentations from all of the breakouts aren't available yet on CommNet...still 3 weeks away.

Link here.

.NET 3.0 - The next revolution

Scott Dorman — Sun, 18 Jun 2006 20:55:00 GMT

Since last years TechEd everyone has been hearing about .NET 3.0 and the cool features of LINQ, lambda expressions, and all of the other cool new language features. I don't know about you, but I was definitely looking forward to them. We were also hearing about WinFx and “Avalon“ and “Indigo“, InfoCard, Windows Workflow Foundation (WWF) and the other new technologies that looked like they would only be part of Vista.

Fast-forward a year to this years TechEd and we're still hearing about .NET 3.0, Windows Presentation Foundation (WPF) and Windows Communication Foundation (WCF), WWF, and CardSpace (InfoCard). Most of us by now understand that WPF is “Avalon“ and WCF is “Indigo“. However, the big change is that .NET 3.0 isn't what it used to be.

In an effort to reduce the confusion in the industry about WinFx, Microsoft is essentially retiring that terminology. The key thing to note is that it is the terminology that is being retired, not the technology. Apparently there was a lot of confusion and concern that Microsoft was abandoning .NET and moving to this new platform named WinFx. What people failed to realize is that WinFx is .NET and is essentially some additional runtimes that sit on top of the .NET runtime.

So, the bottom line is this:

.NET 3.0 == .NET 2.0 + WPF + WCF + WWF + CardSpace

To help sort all of this out, a new community site devoted to .NET 3.0 has been created. According to the site,

The Microsoft .NET Framework 3.0 (formerly WinFX), is the new managed code programming model for Windows. It combines the power of the .NET Framework 2.0 with new technologies for building applications that have visually compelling user experiences, seamless communication across technology boundaries, and the ability to support a wide range of business processes.

Check out the new site at: http://www.netfx3.com/

Windows PowerShell - Unix comes to Windows

Scott Dorman — Sun, 18 Jun 2006 20:18:00 GMT

Windows PowerShell (formerly known as “Monad”) is a Microsoft's answer to the power and flexibility of the Unix command shells. It should finally complete the Windows management picture by providing a solid command line shell to administer Windows systems. PowerShell is part of Vista, but fortunately for all of us, it is being released separately and is available for Windows XP as well.

PowerShell is a command line shell that is:

as interactive and composable as bash/ksh (or any other Unix shell)
as programmatic as Perl or Ruby
as production oriented as the AS400 CL or VMS DCL languages
allows access to data stores as easy as if they were a file system
provides “man-style“ help with a rich schema and searching capabilities

PowerShell seems to have incorporated many of the best features of the Unix shells, such as:

series of profile files that can be run at startup (or logon)
command aliasing
prompt customization
tab completion
many preferences controllable via variables

Scripting

Supports existing scripting models
UNIX model of text processing including regular expressions
Visual Basic Script model of COM automation
Supports scripting .NET objects
Support loose, strong, and extensible typing models
Uniform syntax to access to a wide range of types

WMI, XML, COM, ADSI, ADO

Rich variable semantics (typed, read-only, constraints, descriptions)
Rich operators and control structures (Visual C#-like with access to cmds and utilities)
Functions (positional, named, typed, constrained params)

Text Processing Model

NET String class is the foundation

Clone, CompareTo, Contains, CopyTo, EndsWith, Equals, IndexOf, IndexOfAny, Insert, LastIndexOf, LastIndexOfAny, Length, PadLeft, PadRight, Remove, Replace, Split, StartsWith, Substring, ToCharArray, ToLower, ToLowerInvariant, ToString, ToUpper, ToUpperInvariant, Trim, TrimEnd, TrimStart

Native support for useful datatypes

REGEX, XML, Arrays, Associative arrays,

Rich string operators

+, *, -f, -replace, -match, -like, -eq, -ne, gt, -ge, -lt, -le
Implicit/explicit casting and coercion

Here-strings
Rich control structures
Rich utilities

Select-String, foreach, group, select, sort, where

function top ($property=“Handles”, [int]$count=10)

{
Get-Process | sort $property | select –first $count
}

For those of you who have written Unix shell scripts before (and maybe a lot of people who haven't) the syntax should look familiar. This declares a function named “top” which takes two paramters (both with defaults) and returns a sorted list of the top $count processes sorted by $property.

Windows Vista: Kernel Changes - BitLocker, Code Integrity

Scott Dorman — Sun, 18 Jun 2006 18:18:00 GMT

BitLocker^TM Drive Encryption

BitLocker allows the entire OS volume to be encrypted as well as any other volumes. In order to do this, a 1.5 GB unencrypted system volume is required.

BitLocker requires Trusted Platform Module (TPM) v1.2 or a USB device and USB-capable BIOS and is implemented as a file filter driver that sits just above the volume manager drivers.

There are several supported modes for storing the decryption key:

TPM locked with signature of boot files
TPM locked with user-specified PIN
external USB flash device

Code Integrity Verification

The operating system loader and the kernel now perform code signature checks. On 64-bit x64 platforms, all kernel mode code must be signed and the identity of all kernel mode binaries is verified. The system also audits events for integrity check failures.

On 32-bit platforms, the administrator is prompted to install unsigned code. Load-time checks are done on all kernel mode binaries, but if unsigned code is allowed to load you won't be able to play protected high-definition multimedia content.

Windows Vista: Kernel Changes - Shadows of Reliability, Performance and Scalability

Scott Dorman — Sun, 18 Jun 2006 17:59:00 GMT

Performance and Scalability

Vista makes fewer and larger disk reads for page faults and system cache read-ahead and has removed the 64KB limit. Fewer, faster, and larger disk writes for the system page file and mapped file I/O reduce the page file fragmentation and allow a larger cluster size.

The CPU usage has also been improved by providing improvements in the concurrency management within the kernel.

Windows Error Reporting (WER)

Vista is a more robust and resilient operating system that provides a read-only system cached view of the registry which protects it from being overwritten by drivers and helps reduce data loss in page crashes.

Prior to Vista, unhandled exceptions were handled in the context of the thread incurring the exception. This relied on the thread stack being valid and could result in the “silent death” of applications when the stack was corrupted.

In Vista, unhandled exceptions are sent to the Windows Error Reporting service, which launches Werfault.exe. This replaces Dwwin.exe (Doctor Watson), and permits WER to be invoked for threads that are too corrupted to invoke their unhandled exception handling.

Volume Shadow Copy

Windows Vista now uses Volume Shadow Copy for System Restore and Previous Versions. This creates a point-in-time copy-on-write snapshot of live volumes and solves the problem of open files not being backed up.

The Previous Versions tab was introduced as Windows Server 2003 “Shadow Copies for Shared Folders” feature.

Volume shadow copy now uses the kernel transaction manager for consistent cross-volume snapshots. Snapshots are taken once per day and when system restore points are taken.

Other Reliability Features

The kernel now supports the concept of a “flight data recorder” with the introduction of the circular kernel context logger.

There are new system events for virtual memory exhaustion, which can be used to help capture and report user-mode memory leaks.

The Restart Manager enables most applications and services to be shutdown and restarted to unblock access to DLLs needing to be replaced. This feature may finally allow seamless replacement of in-use DLLs, reducing the number of times a reboot is necessary at the end of an install.

For the developers, there are new debugger APIs that allow for “wait chain traversal” to help find and report deadlocks.

Windows Vista: Kernel Changes - Kernel Transactions

Scott Dorman — Sun, 18 Jun 2006 17:38:00 GMT

Kernel Transaction Manager (KTM)

Before Vista, applications had to do a lot of hard work to recover from errors during the modification of files and registry keys. Windows Vista implements a generalized transaction manager called the Kernel Transaction Manager (KTM) which provides “all or nothing” transaction semantics. This means that changes are committed only when the associated transaction is completed and commits.

The KTM is extensible through third-party resource managers and coordinates between the transaction clients (the applications) and the resource managers.

The registry and NTFS have been enhanced to provide transaction semantics across all operations and is used by the Windows Update service and the System Protection services.

Vista also picks up the Common Log File System (Clfs.sys) introduced in Windows Server 2003 R2, which provides efficient transaction logging facilities.

Transaction APIs

Transactions can span modification across one or many registry keys, files, and volumes. By using the Distributed Transaction Coordinator (DTC) transactions can coordinate changes across files, registry, databases, and MSMQ.

Transactions are relatively easy to use in Vista with the introduction of the new transaction command, which allows scripts to participate in the transaction process.

The Windows API also has a new set of API functions:

CreateTransaction

SetCurrentTransaction

CommitTransaction

RollbackTransaction

The kernel has IoCreateFile, which now has an ExtraCreateParameters which specified the transaction handle.

Windows Vista: Kernel Changes - Wakeup, wakeup, wakeup!

Scott Dorman — Sun, 18 Jun 2006 17:24:00 GMT

Up until Vista, an application or a driver could prevent the system from entering a sleep mode (standby or hibernate) and was often caused by a bug or an overly aggressive power management policy. The problem with this was that the user might not know the system hasn't entered the appropriate sleep stat and eventually loose data.

Vista no longer queries processes when entering sleep states like previous versions of Windows and has reduced the timeout for user-mode notifications to 2 seconds (down from 20 seconds). In addition, drivers can not veto the transition into a sleep state.

Hopefully, these changes will make going to sleep a lot more peaceful.