Future Direction of PatchGuard and ``Anti-Hack'' Systems

In the future, there are a couple of generalized approaches that Microsoft could take to significantly strengthen PatchGuard against attack. Specifically, these involve adding redundancy and removing single points of failure from PatchGuard. It is often helpful to look at an anti-hack system like PatchGuard as a critical system that one would like to keep running at all times with minimal downtime (i.e. a network or service with high-availability). The logical way to accomplish that goal is to locate and eliminate single points of failure, such as by adding redundancy. In a high availability network, one would accomplish this by adding redundant cables, switches, and the like, such that if one component were to fail, the system as a whole would continue to operate instead of failing entirely. With an anti-hack system such as PatchGuard, it is helpful to add redundancy to all critical code paths such that there is no single point where an attacker can simply change an opcode or hook in with the end result of disabling the entire anti-hack system.

Removing these single points of failure is critical to the longevity of an anti-hack system. The main concept to grasp in such cases is that the attacker will always try to seek out the easiest way to break the defenses of the target system. All the obfuscation and encryption in the world does little good if an attacker can simply change a jmp to a nop and prevent elaborate encryption and anti-debugging facilities from ever getting the chance to run. In this respect, PatchGuard is flawed in its current implementation. There are many different single points of failure where an attacker could inject themself at a single place and completely disrupt PatchGuard.

One possible solution to this problem might be to ensure that there are multiple different code paths that can lead to every point in the PatchGuard system integrity check. The nature of the battle between anti-hack systems and attackers relates to how easy it is to bypass the weakest link in the anti-hack system. Until all of the weak links in the system are shored up simultaneously, the system remains much more vulnerable to easy attack or bypass. With this respect, PatchGuard version 2 does little to improve on the weakest links of the system and as such there are still a vast number of ways to bypass it. Even worse, each bypass technique is often only required to attack one specific aspect of PatchGuard in order to disable it as a whole.

As far as PatchGuard itself is concerned, one approach that Microsoft could take to significantly increase the resiliency and robustness of the system to outside interference would be to merge some sort of critical system functionality with the PatchGuard system integrity check. Such an approach would make it difficult for a would-be attacker to simply bypass a call to PatchGuard, as doing so would also bypass some sort of critical system functionality that would (ideally) be required for the system to operate in any usable capacity. At this point, the challenge for attackers then turns into either replicating the critical system functionality that is contained within PatchGuard, finding a way to split the critical system functionality away from the system integrity check portions of PatchGuard, or finding a way to evade PatchGuard's detection of kernel patching entirely. Microsoft can make the first two points arbitrarily difficult, especially since the knowledge of Windows internals is presumably greater inside Microsoft than outside Microsoft. The incorporation of critical system functionality would be theoretically easier for Microsoft to do than it would be for would-be attackers to reliably reverse engineer and re-implement such functionality on their own, forcing would-be attackers to take the hard route of trying to separate PatchGuard from critical system functionality. This is where clever use of obfuscation and anti-debug techniques would really see maximum effectiveness, as an attacker would (optimally) have no choice other than to step through and understand PatchGuard entirely before being able to replicate the critical functionality contained within PatchGuard (or selectively activate the critical functionality without activating the system integrity check).

The latter problem (evading PatchGuard detection entirely) is likely to be a much more difficult one to tackle, however. Techniques such as the clever use of debug registers, TLB desynchronization, and other related attacks are extremely difficult to detect (and typically very easy to alter to avoid detection after a known detection scheme for such attacks is developed). In this particular respect, Microsoft is presently at a great disadvantage. Improving PatchGuard to avoid such evasion tactics is likely to prove both difficult and a poor investment of time relative to how quickly attackers can adapt and compensate for Microsoft's efforts at bolstering PatchGuard's capabilities.

Looking towards the future, it can be expected that PatchGuard will ultimately see the obfuscation-based defensive mechanisms currently in place substituted with hardware-based defensive mechanisms. In particular, the author expects that Microsoft will eventually deploy a PatchGuard version that is augmented by the hardware-based virtualization (also known as hypervisor) support present in recent processors (and being developed for Windows Server ``Longhorn'', code-named ``Viridian''). An implementation of PatchGuard that is guarded by a hypervisor would be immune to being simply patched out of existence (which eliminates some of the most significant flaws in current versions of PatchGuard), at least as long as the hypervisor itself remains secure and free from exploitable bugs. In a hypervisor-based system with PatchGuard, third party drivers would not be permitted to execute with hypervisor privileges, thus completely preventing runtime patching of PatchGuard itself (which would be a part of the privileged hypervisor layer). A hypervisor-based system might also be able to implement concepts such as write-once memory that could be adapted to prevent the kernel from being patched in the first place once it is initially loaded into memory (as opposed to detecting patching after the fact, and bringing down the system in response to third party drivers performing underhanded deeds).

Even with hypervisor support in-place, however, it is anticipated that there will still be ways for third parties to alter the behavior of the kernel in ways not completely authorized by Microsoft. For instance, as long as support for debug registers must be retained in order for the kernel debugger to function, it may be difficult to prevent an approach that utilizes debug registers to modify execution context at arbitrary locations within the kernel (at least, not without making the hypervisor completely responsible for managing all activities relating to the processor's complement of debug registers).