Over the past several years, Microsoft has practically done a one-eighty, becoming a lot more security conscious. This has become quite evident with XP’s Service Pack 2, which enabled the Windows firewall by default. Having the firewall automatically enabled was a major step forward, since it was the one major thing needed to protect the vast majority of novice users, who might otherwise not have enabled the firewall. As is often the case, the experienced users know how to protect themselves; it’s the novice users that need automatic protection.

The newest addition to the Microsoft security arsenal is Kernel Patch Protection, or otherwise known as PatchGuard.

Every operating system has a kernel, and it’s the central component that allows for communication and resource management between the software and the hardware of the system. As such, any tampering with the kernel should be kept to a minimum to ensure the stability of the operating system.

In the past, Microsoft’s “official” policy towards the kernel has been that no developer ought to touch it, but the company has failed to actively enforce this decision. As a result, the kernel has, as Steve Gibson puts it, gotten very little respect from third party developers and their software applications. The reason that almost every software company out there has broken into, or hacked, the kernel is that Microsoft has never released all of the APIs relating to the operating system. This made it very hard, if not impossible, for developers to write software packages such as firewalls, without breaking into the kernel to get the control they needed. Unfortunately, the practice did not stop at security programs; even trivial things, such as printer drivers, rely on access to the kernel.

With the upcoming switch to the first true mainstream 64-bit operating system, Windows Vista, the company has taken the opportunity to finally enforce its policy regarding kernel access with PatchGuard.

Unfortunately, trying to protect the kernel from “illegal” use is not quite as easy as it sounds. The main problem with PatchGuard is that it runs with the same level of protection as the kernel which it is trying to protect. This, by nature, is a flawed mechanic; if you know how the kernel works, you’ll also know how PatchGuard works. So, since the code is inherent in the operating system, it is possible for a skilled programmer to reverse engineer it, so that he or she can then circumvent the protection measures altogether. Luckily, Microsoft has already laid out plans to solve this problem, using hypervisor technology, which would monitor the kernel from another subsystem using virtual machine technology.

Microsoft, knowing about the possibility of workarounds, has tried their best to make the relevant PatchGuard code hard to locate in the first place—in effect securing it through obscurity. Microsoft has used various random number algorithms to randomly scramble the PatchGuard data structure, so that it cannot be located that easily. Regardless of how hard they try to hide it, however, the code still exists in memory, and can, therefore, be located, analyzed, and reverse engineered. In fact, it has already been done. There are various papers already on the Net that explain exactly how to do it—although, I do presume that Microsoft knows about them as well, and has probably fixed the exploits that they use.

What PatchGuard, and other future implementations of kernel protection imply for the end user is that it will be very hard for malicious content to effectively install itself on the host system. A lot of the worst spyware, malware, and rootkits need to hook themselves onto the kernel in order to be effective, and this is what PatchGuard is intended to protect against.

Another added security benefit to locking all third party developers out of the kernel, is that Microsoft is now free to make whatever changes to the kernel that it deems necessary to keep it up to date and as resilient as possible against security threats. In the past, Microsoft did not dare make any changes out of fear that their changes might make a lot of software incompatible.

So, now that hooking the kernel has actually become a dangerous practice, one done at the programmers own peril, it is reasonable to assume that all “good” programs will stay out of the kernel and that anything that does hook the kernel is malicious, and should be made incompatible with a kernel update.

PatchGuard will only affect the 64-bit version of Windows Vista, and not the 32-bit version. This is because there are too many existing “good” applications and drivers out there that rely on modifying the kernel in order to work on Vista, that any kernel protection measure would make a lot of unknowing users rather angry.

PatchGuard is only the first step in Microsoft’s march towards a clean kernel, and if all goes to plan Windows should be a lot more secure in the future…