eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
Perhaps I was naive to think that security vendors would be appeased by Microsofts agreement to work with them around the limitations of PatchGuard.
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.
My moneys on No. 1. Windows, like every software product known to man, has a long list of features there wasnt time to implement. The second option doesnt seem credible; obviously the protections would be necessary. I cant prove the third theory isnt true, but I dont take it seriously.
Next page: Hacking PatchGuard.
Hacking PatchGuard
Many vendors also assert, as McAfee has publicly, that it will always be possible, perhaps even easy, to bypass PatchGuard and that therefore only the good guys get punished. Authentium even announced that it has “hacked” the system to bypass PatchGuard in order to implement products on it. Theres something to this, but not a whole lot. If a security mechanism had to be perfect in order to be implemented, wed all be in big trouble.
Certainly Microsoft never claimed that PatchGuard would be, to use another vendors term, “unbreakable.” But the cracking angle has been greatly overblown. Its highly unlikely that any bypass of PatchGuard could be performed without already having administrator access. Vista already makes it much harder for malware to slip through on the administrator account.
Of course you need such access when you install security programs like Authentiums, but a security company would have to be insane to actually deploy a program that installs itself through a “hack” (to use the companys own characterization of the technique). The moment Microsoft patches the hack, any customers using the product will get blue screens they can blame squarely on Authentium. And PatchGuard has the potential to strengthen, perhaps with the assistance of processor-based virtualization technology.
Anyway, here we are, on the road to developing a solution to the problem. Before it comes out (in Vista SP1), the exposure is limited to certain protections for a relatively small segment of the marketplace. If the security vendors carry the day with their arguments then one of the consequences will be a slowing of adoption of 64-bit Windows. Im not sure whose interests that serves, but its not Microsofts.
The best argument Ive heard against PatchGuard generally is the zero-day argument. The day will come, as one vendor told me, when a threat will emerge that security products can defend against only with kernel patching. If vendors then have to wait months or longer for Microsoft to come out with new APIs then the threat will go unmitigated and customers will suffer. Im not sure this is a realistic scenario, but it smacks of defeatism in that it argues for a fundamentally less secure platform. It cant be the right argument.
So it seems fair to say that Microsoft was late in implementing support for legitimate security vendors to work around the restrictions of PatchGuard, but thats basically old news. What are they supposed to do now? Make the operating system less secure so that security companies can rush in to fill the gap?
Those security vendors who question Microsofts motives in this matter should be careful about their stone throwing. One could easily contrive an argument that they are not so much afraid of Microsofts security products as of a future more secure Windows, one that doesnt have the same need for outside security products. Why else are these same companies busy buying up compliance management firms?
What does PatchGuard really break? It, along with other security advances in Vista, puts the first big crack in the security industrys business model. These ISVs will insist that they want Windows to be secure, but in the end they are ill-served by a truly secure Windows operating system. Lucky for them, unlucky for us, not every attack is controllable by Microsoft, but the tide is turning.
Security Center Editor Larry Seltzer has worked in and written about the computer industry since 1983.
More from Larry Seltzer