Some vendors remain defiant, some concerned. Some who were not concerned all along may simply not implement features that would be impeded by PatchGuard.
After discussing the matter with Microsoft and several vendors whose products would be affected by PatchGuard, a few central observations come through:
- Only 64-bit Windows versions are affected by PatchGuard. Dont listen to people who speak generally of a Vista problem—theyre just trying to create hysteria.
- 64-bit Windows versions, especially desktop versions, have puny market share. Its an oddball, high-end way to run a desktop right now. This will change over time as 64-bit processor systems become cheaper. 64-bit Windows servers are more common, and with Exchange 2007 they may become downright plentiful.
- The problems are limited to what can generally be called HIPS (Host Intrusion Prevention Systems). These are programs that attempt to block certain dangerous actions by programs running on the system.
- Conventional security protection is unaffected by PatchGuard. This includes firewalls, anti-virus, and even some heuristic protection that analyzes code before executing it. Even some operations usually associated with HIPS, such as registry monitoring, can be performed without interference from PatchGuard.
- There is no documented, supported way for vendors to implement key HIPS functions in the face of PatchGuard. At least, not for now.
That last point is the one that matters right now, and why Microsoft had to agree to work with ISVs to provide "documented and supported" methods for them to do their jobs. Behavior blocking, which is what HIPS do, requires the ability to monitor the context of what applications are doing. To do this, programmers need to be able to monitor Windows operations of the most internal nature, such as the creation and manipulation of processes, the creation and movement of memory objects, and image loading.
The discussions Microsoft has had with the vendors, which got off to a procedurally rocky start last week, have centered around a new set of filter mechanisms that would allow for such operations.
Remember that kernel drivers in 64-bit Windows have to be digitally signed with a relatively high-class, expensive certificate from a limited number of certificate authorities. Its theoretically possible to slip malicious code through such protections, but it would be hard to do. It would be even harder to avoid accountability for such an act. If theres some way to ensure that these mechanisms are only executable from signed drivers and that the administrator gets to approve the execution of code with particular signatures, then I guess reasonable precautions have been taken.
PatchGuard has been implemented in 64-bit versions of Windows XP and Windows Server 2003 for some time now. Why hasnt there been a stink about it? Some vendors, Symantec in particular, say that they have been working quietly with Microsoft for all that time to try to get the company to provide a way for legitimate vendors to monitor and control certain system resources in order to protect the system. In fact, they say that Microsofts proposals are not unlike what Symantec has been proposing all along.
Im persuaded by Symantecs argument, to a degree. Im sure Microsoft appreciated at the time it implemented PatchGuard that it would break HIPS programs, and it should have foreseen this problem.
Microsoft tells me that it has been working for some time with ISVs to address these problems. Its true that Microsoft works closely with many of these companies, giving them direct access to developers, office space on the Microsoft campus and joint testing efforts. Its also true that developing new mechanisms for monitoring process and memory operations is serious stuff and takes time.
Even so, Microsoft seems to have gotten off to a slow start. Why did it wait so long to begin the process of accommodating these vendors? Three possibilities:
- It just didnt get around to it.
- It decided that such protections were unnecessary.
- The delay is an effort to gain market share for its own inferior security products.