October 17, 2006
The death of PatchGuard?
Ever write a windows application "the old fashioned way"? For example, does "RegisterClassEx(&myClass)" make you feel
A) happy
B) confused or
C) a sense of angst and overwhelming dread.
If you answered "C", you probably know what I'm talking about. Of course, most folks don't write applications that way any more; ever since the introduction of MFC, ATL, and [insert technology du jour here] there hasn't been much of a need to write this kind of code. Generations of developers have cut their teeth without having to ever worry about window messages or window styles, without ever having to call DispatchMessage() or TranslateMessage(), and without having to wonder about what the hell an HWND is anway. Not that they couldn't write this code if they wanted to - just that there are other technologies available that hide the underlying windowing system from those who have better things to do with their time.
But I digress. The point I'm trying to make is that back in the day, developers were allowed - nay, encouraged - to write to undocumented windows API's. It was a time-honored and glorious tradition; in fact, whole books were published on the subject. Of course, Microsoft never approved of it; they would rename undocumented functions to things like "BOZOSLIVEHERE" and "TABTHETEXTOUTFORWIMPS" to highlight the fact that you shouldn't be doing whatever it is that you were doing. But PatchGuard changes the paradigm. Now, instead of calling you a wimp or a bozo for using undocumented functions, Microsoft is doing something more - telling you that undocumented API's will halt the machine. Not an entirely bad decision in my opinion (although I would argue that maybe halting the app might be a better course of action than the blue-screen but maybe that's harder,) but I've covered that ground before so I won't do so again.
I read a few articles this morning about PatchGuard and about how Microsoft has apparently backed off their position in regard to PatchGuard. They've apparently decided to "allow access" to certain API's that SYMC and McAfee want to use; they've also decided to make an API available to programmatically disable the Windows Security Center. So, here's my question. Are SYMC and McAfee the only ones who can use undocumented API's on 64-bit Vista? Of course not. Are SYMC and McAfee the only ones who are going to be able to disable the security center? Nope. In the interests of fairness, that functionality has to be available to everyone. Small AV players, anti-spyware vendors, HIPS vendors, encryption vendors, non-security application developers, malware authors, old Uncle Jerry who talks to himself... everyone.
So I have to ask myself if this is a victory for security? It's a victory for Microsoft certainly: they get the publicity associated with developing new security features without the pain and inconvenience of having to actually support them; they get the perception of "fostering competition" at the same time that they also get a convenient excuse for insecurities in the product ("we tried to secure it, but were forced to back down"). It's also a victory for AV vendors: they get to programmatically disable the Windows Security Center and secretly replace it with Folgers crytstals - for OEM systems (those that come with either McAfee or SYMC preinstalled,) end users might not even realize that they had a choice of security centers in the first place. Symantec and McAfee also get to use undocumented Vista API's regardless of stability or performance concerns. Sounds like a win to me. But what do users get? One less security feature? Maybe. Lack of choice in Security Centers? Arguably. Increased succeptibility for malware? Could be. Call me inflammatory, but I think this was a zero-sum win: Microsoft made out big, McAfee made out so-so, and users got the short-end. But that's just my opinion...
Posted by Ed at October 17, 2006 08:36 AM | TrackBack