PatchGuard versus Rootkits

There has been some confusion centering around whether or not PatchGuard can be viewed as a deterrent to rootkits. On the surface, it would appear that PatchGuard does indeed represent a formidable opponent to rootkit developers given the fact that it checks for many different types of hooks. Beneath the surface, it's clear that PatchGuard is fundamentally flawed with respect to its use as a rootkit deterrent. This flaw centers around the fact that PatchGuard, in its current implementation, runs at the same privilege level as other driver code. This opens PatchGuard up to attacks that are designed to prevent it from completing its checks. The authors have previously outlined many different approaches that can be used to disable PatchGuard[36,37]. It is certainly possible that Microsoft could implement fixes for these attacks, and indeed they have implemented some in more recent versions, but the problem remains a cat-and-mouse game. In this particular cat-and-mouse game, rootkit authors will always have an advantage both in terms of time and in terms of vantage point.

In the future, PatchGuard can be improved to leverage features of a hypervisor in a virtualized environment that might allow it to be protected from malicious code running in the context of a guest. For example, the current version of PatchGuard currently makes extensive use of obfuscation in order to presumably prevent malware from finding its code and context structures in memory. The presence of a hypervisor may permit PatchGuard to make more extensive use of immutable memory, or to alternatively run at a privilege level that is greater than that of an executing guest, such as within the hypervisor itself (though this could have severe security implications if done improperly).

Even if PatchGuard is improved to the point where it's no longer possible to disable its security checks, there will still be another fundamental flaw. This second flaw centers around the fact that PatchGuard, like any other code designed to perform explicit checks, is like a horse with blinders on. It's only able to detect modifications to the specific structures that it knows about. While it may be true that these structures are the most likely candidates to be hooked, it is nevertheless true that many other structures exist that would make suitable candidates, such as the SuspendApc of a specific thread. These alternative candidates are meant to illustrate the challenges PatchGuard faces with regard to continually evolving its checks to keep up with rootkit authors. In this manner, PatchGuard will continue to be forced into a reactive mode rather than a proactive mode. If IDS products have illustrated one thing it's that reactive security solutions are largely inadequate in the face of a skilled attacker.

PatchGuard is most likely best regarded as a hall monitor. Its job is to make sure students are doing things according to the rules. Good students, such as ISVs, will inherently bend to the will of PatchGuard lest they find themselves in unsupported waters. Bad students, such as rootkits, fear not the wrath of PatchGuard and will have few qualms about sidestepping it, even if the technique used to sidestep may not work in the future.