Conclusion

The development of a solution that is intended to mitigate the unauthorized modification of various critical portions of the kernel can be seen as a rather daunting task, especially when considering the need to ensure that the routines actually used for the validation of the kernel cannot be tampered with. This document has shown how Microsoft has approached the problem with their PatchGuard implementation on x64-based versions of the Windows kernel. The implementations of the approaches used to protect the various critical data structures associated with the kernel, such as system images, SSDT, IDT/GDT, and MSRs, have been explained in detail.

With an understanding of the implementation of PatchGuard, it is only fitting to consider ways it which it might be subverted. In that light, this paper has proposed a few different techniques that could be used to bypass PatchGuard that have either been proven to work or are theorized to work. In the interest of not identifying a problem without also proposing a solution, each bypass technique has an associated list of ways in which the technique could be mitigated by Microsoft in the future.

Unfortunately, Microsoft is at a disadvantage with PatchGuard, and it's one that they are perfectly aware of. This disadvantage stems from the fact that PatchGuard is designed to run from the same protection domain as the code that it is designed to protect from. In more concise terms, PatchGuard runs just like any third-party driver, and it runs with the same set of privileges. Due to this fact, it is impossible to guarantee that a third-party driver won't be able to do something that will prevent PatchGuard from being able to do its job since there is no way for PatchGuard to completely protect itself. Since this problem was known going into the implementation of PatchGuard, Microsoft chose to use the only weapons readily available to them: obfuscation and misdirection. While most consider security through obscurity to be no security at all in the face of a sufficiently motivated engineer, it does indeed raise the bar enough that most programmers and third-party entities would not have the interest in finding a way to bypass it and instead would be more motivated to find a condoned method of accomplishing their goals.

In cases such as this one it is sometimes important to take a step back and consider if the avenue that has been taken is actually the right one. In particular, Microsoft has decided to take an aggressive stance against patching different parts of the kernel in the interest of making Windows more stable. While this desire seems very reasonable and logical, it comes at a certain cost. Due to the fact that Windows is a closed source operating system, third-party software vendors sometimes find themselves forced to bend the rules in order to accomplish the goals of their product. This is especially true in the security industry where security software vendors find themselves having to try to layer deeper than malicious code. It could be argued that PatchGuard's implementation will prevent the malicious techniques from being possible, thus freeing up the security software vendors to more reasonable points of entry. The fact of the matter is, though, that while security software vendors may not make use of techniques used to bypass PatchGuard due to marketing and security concerns, it can certainly be said that malicious code will. As such, malicious code actually gains an upper-hand in the competition since security vendors end up with their hands tied behind their back. In order to address this concern, Microsoft appears to be willing to work actively with vendors to ensure that they are still able to accomplish their goals through more acceptable and documented approaches.

Another important question to consider is whether or not Microsoft will really break a vendor that has deployed a solution to millions of systems that happens to disable PatchGuard through a bypass technique. One could feasibly see a McAfee or Symantec doing something like this, although Microsoft would hope to leverage their business ties to ensure that McAfee and Symantec did not have to resort to such a technique. The fact that McAfee and Symantec are such large companies lends them a certain amount of leverage when negotiating with Microsoft, but the smaller companies are most likely going to not be subject to the same level of respect and consideration.

The question remains, though. Is PatchGuard really the right approach? If one assumes that Microsoft will aggressively ensure that PatchGuard breaks malicious code and software vendors who attempt to bypass it by releasing updates in the future that intentionally break the bypass approaches, which is what has been indicated so far, then it stands to reason that Microsoft could be heading down a path that leads to the kernel actually being more unstable due to more extreme measures being required. Even if Microsoft extends its hand to other companies to provide ways of hooking into the kernel at various levels, it will most likely always be the case that there will be a task that a company needs to accomplish that will not be readily possible without intervention from Microsoft. Unless Microsoft is willing to provide these companies with re-distributable code that makes it so third-party drivers will work on all existing versions of x64, then the point becomes moot. Compatibility is a key requirement not only for Microsoft, but also for third-party vendors, and a solution that won't work on all versions of the x64 kernel is no solution at all for most companies.

If Microsoft were to go back in time and eliminate PatchGuard, what other options might be exposed to them that could be used to supplement the problem at hand? The answer to this question is very subjective, but the authors believe that one way in which Microsoft could solve this, at least in part, would be through a better defined and condoned hooking model (like hooking VxD services in Windows 9x). The majority of routines hooked by legitimate products are used by vendors to layer between certain major subsystems, such as between the hardware and the kernel or between user-mode and the kernel. Since the majority of stability problems that third-party vendors introduce with runtime patching have to do with incorrect or unsafe assumptions within their hook routines, it would behoove Microsoft to provide a defined hooking model that expressed the limitations and restrictions associated with each function that can be hooked. While this might seem like a grand undertaking, the fact of the matter is that it's not.

By limiting the hooking model to exported routines, Microsoft could make use of existing documentation that defines the behaviors and limitations of the documented functions, such as their IRQL and calling restrictions. While limiting the hooking model to exported functions does not cover everything, it's at least a start, and the concepts used to achieve it could be wrapped into an equally useful interface for commonly undocumented or non-exported routines. The biggest problem with this approach, however, is that it would appear to limit Microsoft's control over the direction that the kernel takes, and in some ways it does. However, it should already be safe to assume that exported symbols, at least in relation to documented ones, cannot be eliminated or largely changed after a release as to ensure backward compatibility. This only serves to bolster the point that a defined hooking model for documented, exported routines would not only be feasible but also relatively safe.

Regardless of what may or may not have been a better approach, the lack of a time machine makes the end result of the discussion mostly meaningless. In the end, judging from the amount of work and thought put into the implementation of PatchGuard, the authors feel comfortable in saying that Microsoft has done a commendable job. Only time will tell how effective PatchGuard is, both at a software and business level, and it will be interesting to see how the field plays out.