Microsoft has long claimed that the best reason for upgrading to Windows Vista is to take advantage of all of the new security features. One of these new features is PatchGuard, a mechanism for preserving the integrity of various operating system (OS) components. Unfortunately, PatchGuard's protection is not as comprehensive as it might at first seem. In this article, I will explain why this is the case.
Before you can truly appreciate PatchGuard and what it does, here's a bit of historical background. Normally, when application developers code a Windows-based application, they use an application programming interface (API). An API provides a standardized, structured way for the application to interact with the Windows OS.
The problem with using an API is that it forces the application to play by OS rules. It also somewhat limits what the developer can do and for years some software developers have chosen to work around the various APIs.
While there isn't really anything wrong with working around an API, some software publishers take it one step further and use a coding technique called kernel hooking. Kernel hooking refers to the practice of replacing one of the kernel-level OS files with a modified version created by the software developer. Typically, this technique allows the application to use the kernel hook to bypass various OS safeguards and gain a deeper level of access to the OS or to the underlying hardware. This practice is especially common among software companies that develop antivirus products and other types of security products.
Microsoft has denounced the practice of kernel hooking. Depending on how the kernel hook is written, it can cause Windows to experience various stability and performance problems. Other applications may also cease to function correctly. After all, imagine what would happen if two different applications both attempted to replace the same kernel file with modified versions. I suspect that the main reason why Microsoft denounces the practice has to do with its inability to support something that has been modified.
Although kernel hooking was originally used with legitimate security programs, it wasn't long before malware authors jumped on the bandwagon. Kernel hooking is the process that makes creating rootkits possible. Most IT professionals no doubt remember the events of 2005 when the music industry was busted embedding rootkits in music CDs. Those rootkits used kernel hooking to modify the Windows kernel files in a way that would prevent music CDs from being copied. They designed rootkits in such a way as to mask any files or registry keys starting with $sys$, thus making it easy for malware authors to create malicious code that would be hidden by the existing rootkit.
Initially, it seems that PatchGuard would be the perfect solution to preventing kernel hooking, something that Microsoft realized several years ago. PatchGuard was actually introduced in Windows Server 2003 and Windows XP under the name Kernel Patch Protection.
So with Kernel Patch Protection now in the picture, why is it still possible to hook kernel files? One reason is that Kernel Patch Protection only exists on 64-bit versions of Windows. So many 32-bit programs exist that take advantage of kernel hooking that Microsoft did not want to risk having a major compatibility problem on its hands by implementing Kernel Patch Protection in 32-bit versions of Windows. At the time, so few application vendors were publishing 64-bit code that Microsoft decided it could safely implement Kernel Patch Protection into 64-bit versions of Windows without causing major problems for the entire software industry. Even today, PatchGuard still only runs on 64-bit systems.
Another reason why Kernel Patch Protection has been relatively ineffective so far is because it does not protect the entire OS. Kernel Patch Protection only provides the following types of protection:
- Applications are prohibited from modifying the system service tables.
- Applications are not allowed to modify Interrupt Descriptor Tables.
- Applications cannot modify the Global Descriptor Table.
- Applications cannot use kernel stacks that are not allocated by the kernel.
- An application cannot patch any part of the kernel.
The same restrictions are still in effect today with Windows Vista's PatchGuard. Supposedly, PatchGuard will eventually provide other types of protection.
It's going to be interesting to see what happens with PatchGuard. Some software companies have already created versions of their software that can circumvent PatchGuard, and several hacker websites have published tools for or articles on the subject of circumventing PatchGuard. Microsoft has created patches to block the various circumvention techniques.
If history is any indication, I think kernel hooking will always be something of a cat and mouse game. Hackers will continue to find new kernel hooking techniques, which will eventually be blocked by operating system patches.
Personally, I believe that PatchGuard and Kernel Patch Protection are good things. While it is obvious that these features are not capable of completely preventing rootkits, my hope is that they will send a message to legitimate software developers that they need to code their applications in ways that do not require modifications to the Windows kernel. When legitimate applications stop behaving like rootkits, it will become much easier to detect any rootkits that do make it onto the system.
About the author: Brien M. Posey, MCSE, has received Microsoft's Most Valuable Professional Award four times for his work with Windows Server, IIS and Exchange Server. He has served as CIO for a nationwide chain of hospitals and healthcare facilities, and was once a network administrator for Fort Knox.
