Pig Pile on Microsoft

I am wavering a bit on my position on the MS Vista KPP/ PatchGuard debate, but there is so much rhetoric going on that it is difficult to actually get any facts on either side.

In general, I think KPP is "A Good Thing" and the positions held by Symantec, McAfee et. al. regarding how good security vendors are at providing security and how there should be a small group of "chosen one" vendors with better access are pretty shallow. I think most folks involved in the controversy agree with my former position, but half will likely disagree with the latter. KPP is no panacea, but it provides a valuable function.

So, the question is whether there is validity to S&M's (;-)) claims once you peel away the posturing. I think there is the possibility that they have a point. The initial example that I saw on Security Curve just seemed self-serving once again, but this post on Symantec's blog provides much better insight. At least we know what hooking technique PatchGuard is blocking - SSDT hooking.

But there are a number of techniques that folks can use to monitor activities. I suspect most/all of those are also restricted by KPP, but I am not sure. If they aren't, then there isn't really a problem (though it would seem that KPP is less effective than I would like). If they are restricted, then what other techniques might exist to provide this capability?

Getting to the bottom of the "other techniques" is problematic. In my mind, the biggest problem is that the HIPS players out there aren't chiming in on the pig pile. Why not? As far as I can tell, they have the most to lose here. I did here from one vendor that said it wasn't a problem for them. So, if there are other techniques (yes, even if they are in user mode), then I believe the advantage goes to Microsoft.

On the other hand, the closest set of details I've seen about this were on Stephen Toulouse's (Stepto) blog where he asserts:

"Examples of documented APIs that our teams are investigating with third parties include control over process/application launch and manipulation, prevention of tampering and unauthorized modification of security software, and visibility/control into memory management functions such as writing into another process’ memory address space."

Since they are "investigating" these capabilities, then it is safe to assume they don't exist today (back to the question of alternative legitimate techniques). These are all HIPS capabilities... so where are the HIPS folks? (I know, I know S&M have HIPS products, but to date they really haven't gone out of their way to describe any specific technical differences between av and hips.)

If there are no other ways to (at a minimum) keep an application from running, then this is a bigger problem than I originally thought. Microsoft backpedaled significantly here (though Stepto's blog insists they didn't), so I guess I can, too.

The other issue worth addressing is this whole competitive advantage question. Microsoft claims no competitive advantage because their solution must abide by the same rules for the APIs that are available. Symantec says that doesn't matter, because MS products aren't as advanced as theirs and they need more capability (i.e. the HIPS stuff above). So it doesn't matter that MS plays by the rules with the old stuff; it is the newer stuff that matters.

If Microsoft releases a HIPS product in conjunction with their extended API, you gotta wonder if there is something fishy going on. If there are other ways to monitor system calls, it shouldn't matter anyway. If there aren't other ways, then Symantec has to come up with other ways to talk about the issues that aren't so political.

I am still researching these (technical) issues, so if you have any good specifics, please comment or send me an email.

Btw, the whole webcast whining is silly.

Comments

[Ryan Russell]

Simply looking at what technical measures are used to do the blocking is missing the point. Anything else running in Ring 0 will be able to compromise and patch the kernel if it ultimately wishes to, it's just work. Your own signed driver or a hole in another driver or the kernel itself will do fine. You can bet the bad guy will get in the kernel.

The problem is that Microsoft has now declared the kernel verboten. As in, at any moment, they might drop a patch that kills your hook. So, you need an offically supported hooking mechanism.

[Pete]

Ryan -

No doubt, but I am hard pressed to suggest that MS shouldn't be able to try to defend their own kernel. Not to muddy the waters or anything, but the whole possibility of liability really forces this need.

[Ryan Russell]

I don't think anyone wants Microsoft to not make the attempt to protect the kernel. Consider these points:

-Liability? Since when has there been such a thing as liability for software?

-Are "defending" the kernel from (some, all) programmers, and allowing 3rd party security software in really mutually exclusive?

-When the bad guys get into the kernel, what would you like to do about it? Should security software be allowed to try and go after it? Should you always just have to wipe and reinstall? Will Microsoft's own competing security software have a way to do that?

-Assume for sake of arguement that you think 3rd party software vendors should try to go after kernel threats. Should they use the same kinds of techniques as the malware itself to get there, with any stability problems that might create? Or should they have a supported interface that gets updated, fixed, and shouldn't destabilize the system?

-If 3rd party vendors have to pull tricks to get in the kernel, will Microsoft break them with every patch? Should Microsoft declare yours an unsupported configuration if you have intentionally installed software that hooks the kernel?