October 06, 2006
Thoughts about McAfee's advertising blitz
Unless you've been living under a rock for the past two days, you've probably already heard about McAfee's full-page ad in the Financial Times doing down the big M and alleging that new features are blocking their ability for their product to function. Even more recently, they've gone on the public record to say that Vista's security will be reduced because of (ironically) two new security features that Microsoft is building into the product.
Here's the argument: Microsoft has built a feature in to Windows Vista for the 64-bit platform that prevents folks from monkeying around with the kernel in unsupported ways (through a technology appropriately called "Patchguard"). Given that there are quite a few companies doing this, Microsoft has elected to target the 64-bit platform first so as to reduce the overall impact. However, probably in future it will expand to the 32-bit architecture as well. Microsoft alleges that by doing this, they can help users ensure reduced rootkit problems and greater stability. Now, McAfee and Symantec allege that by locking down the platform in this way, that Microsoft impedes their ability to sell product. Also, McAfee and Symantec are in a twist because of the fact that you can't programatically disable the Windows Security Center that reports on AV installation status; they say that this impedes their ability to compete because they can't programmatically disable the Security Center.
So, when I first read the press coverage of this, it sure sounded to me like Microsoft was being anti-competitive; but then I decided to educate myself on the various features that are under discussion - now I have a different opinion. Now I think that McAfee and Symantec are grandstanding. Why's that, you ask? Well, here's my take on this stuff:
Patchguard: If you take a look at the technical overview put out there by Microsoft's Patchguard architect, Jeff Jones in his blog or if you look at the Vista kernel protection FAQ, you'll notice that there is a subtle difference between what McAfee and Symantec are claiming vs. what the feature actually does. McAfee and Symantec claim that you can't write certain types of code that interact with the kernel; however, that's not what the technology does. Instead, the technology prevents products using undocumented and unsupported techniques for modifying the kernel. Take a look:
Was this kernel add-on part of the overall design? It can be, and if so, there should be predictable, well-defined interfaces that help it fit into the designed architecture. Otherwise (ie using non-documented methods), behavior is unpredictable at best... Of course, there is a difference between a driver developed by, say Hewlett-Packard, and some unknown code posted for shareware download. The former should be allowed to extend the kernel in defined/designed ways (ie. so your printer works) that the latter perhaps should not. The method for that on x64 is Kernel Mode Code Signing.
So, your options if you're SYMC or McAfee are use defined interfaces and sign your driver. That's not so onerous - HP has to do it for their printers to work, Canon has to do it for their scanners to work, and Western Digital has to do it for their harddrives to work. Seems to me like McAfee should have to do it too. In fact, it's not just about fairness - I *want* McAfee to use documented interfaces. I *want* them to sign their driver. Why would I want anybody - including McAfee - to modify the kernel in a way that's unsupported, undocumented, and untested? And frankly, it scares the hell out of me that they would fight to retain their ability to use the undocumented interfaces in the first place.
Now, somebody at McAfee might say that there are features that they can't do because they can't hook the kernel using "scary undocumented interface X". However, I would ask them what those things might be; without some kind of specific example, I don't believe it. Specifically, I find it hard to swallow that a vendor like Aladdin can write a filesystem driver that filters USB requests to encrypt data on the fly using documented interfaces, that a vendor like CA can write a driver that filters all incoming TCP connections using documented interfaces, and that a vendor like PointSec can write a driver to intercept filesystem calls using documented interfaces; but somehow McAfee can't get it together to grep the filesystem for malware without "going commando" all over Windows Vista in a way that requires them to rewrite the kernel. WTF?! The answer is: they can do it and they will do it. So what's motivating the outrage in the meantime?
Security Center: According to the outrage from McAfee et al, the way that the Windows Security Center is handled in Vista is also a problem; this has been represented in the press as Microsoft "forcing" users to use the Microsoft version of the security dashboard. Well, I guess technically that's one way to say it; of course, another way to say it is that the feature prevents third parties from disabling the security center without user approval. From a user-choice perspective, the security center recognizes and integrates with third party products, was designed with openness in mind to facilitate this, and provides the user the ability to turn it off if they want to. What's causing the ruckuss is that the user will actually have to make a decision to diable it rather than allowing Symantec or McAfee to nuke it for you.
Again, as with Patchguard, I want this. I *want* to make the decision about which vendor controls the security dashboard and I don't want McAfee to take that decision away. I'm not going to use the Windows Security Center because I find it irritating, but I'm not going to use McAfee's or Symantec's either - for the same reason. In general, I don't want McAfee making decisions for me about what Windows features are enabled or disabled just like I don't want Microsoft deciding for me what browser I should use. It seems to me that in this case, Microsoft - by enforcing the user's decision to choose what dashboard to use - is more about openness than McAfee's ire about not being able to dictate to the user what security dashboard they'll use.
Posted by Ed at October 6, 2006 09:15 AM | TrackBackYes, feel your anger at being lied to. Your friends can not help you now!
Hi. I'm the VP of Engineering here at Symantec, and I am responsible for building our consumer products.
I have been in the press quite a bit lately discussing the technical issues behind both Patchguard and Windows Security Center. Microsoft is trying to hide the real issue here, and the facts are quite simple.
Patchguard is a good idea, and we are not asking for it to be disabled or turned off. We are asking for a secure exception for well known security companies.
First, MS says (and you have repeated) that all we have to do is sign our drivers and use supported interfaces. You also go on to say that others (Aladdin, CA, etc.) have figured out how to hook to OS, so why can't we?
This is not the issue. First, our drivers are signed, and always have been. Second, we do use the very same interfaces that Aladdin and CA and just about every other security vendor use. In fact we here at Symantec led the industry in driving MS to publish said interfaces.
The point here is that MS, CA, Aladdin and others use ONLY the supported interfaces, because they don't offer the more advanced security for which there ARE NO INTERFACES!
You ask for a specific example, so I will give you one:
For the last two years, many trojans, worms, rootkits, spyware and viruses have been implementing "retro-viral" behavior. In short, this means that upon being installed on the system, the first activity these threats take is to destroy or disable the security protection on the computer.
These retro-viral techniques have become quite popular and many threats these days use them. When we predicted this, we added functionality called tamper protection, to prevent those threats from disabling or destroying our software. The results have been terrific; witness the latest PC Magazine review of NIS 2007 where Neil Rubenking points out that he could not disable or destroy the security defenses. Since implementation of this technology, retro-viral threats have all but ceased to be a problem for customers of the Norton product.
Unfortunately tamper protection relies on the access to the operating system that we have always had, and which MS's PatchGuard policy specifically DISALLOWS! The net result is that no 64-bit systems, Norton customers will no longer be protected from retro-viral threats, and there are MANY of these threats out there.
MS further confuses this issue by saying that they are being "fair" because they have to play by the same rules. What they don't say is that they have only implemented the interfaces for the security technologies that THEY themselves offer! If and when they get around to realizing that they have to implement some of these more advanced techniques, they will be able to modify the kernel to provide supported interfaces. Noone else in the security industry has the ability to change the kernel as MS does.
As I have said earlier, the end result is less security for customers. I am responsible for providing security for my customers, and I cannot stand-by while MS hamstrings their competitors, and reduces security for the masses.
It just isn't true. We have been talking to MS about this for over 2 years, and proposing secure alternatives and exceptions for signed and well-known security vendors.
At the end of the day, think about the customer: When a customer of 32-bit windows who IS protected against the Bancos trojan switches to 64-bit and is NO LONGER protected, how do you think they will feel about this issue?
Finally, one has to look at the underlying issue here. MS was much more receptive to working with us BEFORE they decided to start selling their own security software. Since that time, issues like this (Patchguard), have followed the all to familiar pattern of MS leveraging their monopoly over the OS to squeeze out competition. It's one thing when this behavior results in less choice for customers in terms of browsers and media players, but it has far more serious and disastrous effects when it results in a security monoculture.
I would be happy to discuss the WSC issue as well if you are so inclined.
Posted by: Rowan Trollope at October 6, 2006 03:15 PMRowan,
You make a reasonable argument, but it seems to get a bit soft and vague in the middle and near the end. For example, it seems like if you have Symantec on-access antivirus running and loaded via the Vista APIs, that it could detect and stop the installation of Troj/Bancos before it started its antiviral activity. True, this may not be so for a zero day unknown one for which there are not signatures, but that has always been the weakness of AV.
Second, could you give a little more detail about the Bancos trojan and how it would succeed against x64 Vista? I got this description from Sophos: "Troj/Bancos-BM copies itself to the Windows folder as regeditnt.exe and sets the following registry entry to ensure it is run on Windows login: HKLM\Software\Microsoft\Windows\CurrentVersion\Run
Service Registry NT Save
%WINDOWS%\regeditnt.exe" Can you confirm this is correct?
If so, your strong assertion that x64 Vista customers would not be protected seems ... er ... exaggerated. My understanding is that Vista protects pretty well against this stealthy attempt to both copy an exe into the Windows directory and also to insert something into "Run" registry in a couple of ways.
Additionally, even if not, it seems that the new Registry Monitoring capabilities in Vista would give you an approved interface that would specifically let you monitor for the attempted registry change as needed. I understand that this may not be the exact technique you currently use as cited above, but it seems like it could work.
Now, I do not doubt that there are types of behavior blocking that you can't do with Patchguard in place. However, in my opinion, the example you've given, when researched, just seems to support the Microsoft statements about improved security and not the case you're trying to make.
For me, I'd like to see you working hard to implement with the interfaces in Vista while requesting additional necessary interfaces in parallel. Here is my question for you - setting aside your request to be able to bypass patchguard for a moment - what other specific APIs (to support your innovation) have you requested Microsoft add to Vista that they have refused to add?
Posted by: John Brazil at October 6, 2006 06:49 PMHi John,
I can be very specific. My post was long enough as it was, but the specific details, as you point out, are critical to understanding why this issue is so important.
First, let me address the issue of using supported APIs when available: We always try to go this route first. Furtermore, we try to work with MS to suggest changes or additions to make those APIs work better. In fact, as I pointed out earlier, we have been the driving force behind many of the APIs that other Security vendors rely on today.
It should be obvious that using supported APIs makes our life easier. Only when there is NO API do we resort to Kernel patching. The cost of Kernel patching is always much higher than an API, so we always look the standard route first.
Second, let me address the specific issue of how Patchguard reduces security immediately:
There are many examples I could give here, but perhaps the easiest to understand is a feature we call tamper protection. To be clear, if there were APIs to do these things we needed, we WOULD be using them. There are not. The registry APIs you highlight are a small subset of the necessary functionality. When a threat attempts to disable our software, they do so using many different and insidious techniques, deleting DLLs, overwriting our memory space, killing our processes, destroying other system components which we rely on, mucking with our settings files, etc.
We had to develop a technology which would make us impervious to attack, and we did so.
One example of this in action is the Bancos trojan -- if you install the trojan, go look at the Tools menu and notice that there is a "Disable Mcafee" menu item. An attacker now simply loads the trojan onto a target host, and then selects to disable Mcafee, and then party on the computer. Notice that there is no "Disable Symantec", that's because since implementing our tamper protection, it has gotten almost impossible for malicious apps to harm our protection.
But it doesn't stop there; we have two new peices of technology in Norton Confidential 2007 which will block both the keyboard hooking and screen capturing techniques used by Bancos. These also rely on Kernel patching.
In addition, there are a handful of other advanced security techniques which we implement using Kernel patching, none of which have supported APIs. These include our Shields technologies, and Behavior Blocking technology.
Finally, let me close with the most troubling aspect of the Patchguard policy; the chilling effect it will have on innovation.
The underlying issue here isn't one or two specific examples -- its what happens when MS becomes a choke point for innovation? What happens when we can no longer put the security of customers first, and have to "ask Microsoft" any time we want to innovate or come up with some new way to protect customers? I can assure you that the speed of execution of MS on providing APIs will not be reassuring to customers.
Perhaps the biggest concern isn't the effect Patchguard will have on TODAY's security, but the effects it will have on tomorrow's security.
What should I do when the NEXT threat comes along and my engineers come up with a fix. Should I hold that back and wait to see if MS agrees to my approach, and then agrees to provide a standard interface? What happens to the customers who are meanwhile exposed to such a threat, while I sit on a potential solution, unreleased to customers, because of this Patchguard policy?
And the situation is not just bad for customers of Symantec products, it affects the entire industry, perhaps most importantly, the smallest security companies.
Consider for instance that there are a handful of innovative companies out there today who have been creating completely different approaches to security, such as Greenboard and SecureOL, to name just two. You can imagine that these different approaches are likely to run into uncharted waters where APIs may not exist. These small companies will also not have the werewithal to make their voice heard within MS. What happens to them?
We have (for over two years), been espousing this position directly and quietly with Microsoft alone. We have proposed secure APIs which allow for security companies to continue to offer advanced security with Kernel patching, while allowing Patchguard to do its job.
Hope that clears things up.
Posted by: at October 7, 2006 01:14 PMI realize I'm a bit late to the party in terms of commenting on this, but I wanted to make sure that I had a chance to think it through before commenting.
So, I don't think the issue is about Patchguard - or Windows Security Center - or Vista. It seems to me that all these issues are symptoms of a larger problem; specifically, there's a broader question about Microsoft's motivation for introducing these features.
Here's what I mean: Patchguard makes sense from a security perspective; specifically, it makes sense (from a rootkit-prevention standpoint) to limit what aspects of the kernel software can modify and interact with. From a pure "software architecture" perspective, they intend to technically enforce the boundaries of their components to prevent undesireable consequences. And I can't say that I blame them. However, by doing so, they also open up the possibility that this feature could be used to stifle competition - they could, for example, deliberatly limit what API's are exposed to others while retaining their own ability to use undocumented API's. Now, I'm not convinced that they're doing that, but then again I'm not an architect on an AV product. :-) However, even if they aren't doing this now, we still have to consider that it's possible for them to do so *and* that there's precedent for them doing exactly this in the past (IE, Office, DevStudio.)
If they keep their word, the folks over in the OneCare division are going to be using the same set of API's as SYMC. If that's the case, then their Patchguard feature is not anti-competitive. So, is their motivation fueled by the desire to increase the security of Vista? Or is their motivation fueled by their desire to hamstring competitors in the AV space? I don't think we know yet for a fact either way. Clearly there is a security benefit, clearly there is a possible danger (either now or in the future.)
Ultimately, I guess the proof will be in the pudding. It's fairly easy to tell what API's are being used by OneCare, there are likely to be quite a few eyes on it, and I think SYMC will have quite a bit of supporting outrage from the community if it should turn out that MSFT's using API's that aren't available to others. However, in the meantime, I think that the security benefit of this feature outweighs the perceived danger that MSFT could get a "leg up" over SYMC/McAfee by cheating. But that's just my opinion.
Posted by: Ed at October 9, 2006 10:53 AMAfter reading the discussion above, can I venture a problem from security kindergarten?
I want to turn off my computer (WindowsXP 2000, Home edition, Gateway, with Office 2003 installed). There on the "Turn off computer" icon is the McAfee shield telling me Windows updates are available. I run them and watch "1 of 13 being installed", etc. through "13 of 13 being installed." At some point after that I got a message: "Not installed" followed by a list of 13 updates not installed. Each has a title followed by "(KB+6 digits)." From this I gather that they are MS products, not McAfee's. This surprised me at first because looking at the array of Services offered at the McAfee Security Center "home page," each of them extensively elaborated, I thought McAfee did it all.
My surprise was not diminished when in a subsequent chat with a McAfee tech I learned that the installation failure was not caused by a conflict with McAfee, that I needed the MS security products, and that MS might be able to solve the installation problem.
My computer is out of warranty, but it has been so since early 2005 and I've successfully installed Windows updates since then until maybe three weeks ago.
A Gateway tech confirms that MS has the solution to my installation problem. He tells me that Office 2003 is the latest MS version, that if I want any further updates I have to buy a later version of Office, and that none are available except for Office 2007, which is for businesses only.
If so, I now ask readers, why am I, a personal user, getting McAfee notices for available Windows security updates?
Another McAfee tech tells me that McAfee Remote Support --my kind of support-- is available. The cost is over my head though.
So my immediate practical problem is that I cannot install the Windows security updates that McAfee says I need.
McAfee Security Center tells me all my services are up-to-date, and RegCure says 108/108 errors in my registry have been cleaned as of this morning.
More generally, in terms of apples and oranges, how do the Windows and McAfee security products work together on the same computer?
If and when anyone answers this, could you notify me somehow? I suspect putting my email address here would not be a good idea?
Father Fred
Ouch. This sounds like a whopper of a problem; firstly, I would tend to agree with you that the patches that you are missing are Windows security patches (given the "KB" designation - for "Knowledge Base" probably.) Given that they are likely to be windows-related security issues, I would advise you to steer clear of using McAfee to apply the updates (no offense to McAfee, but it could be that this avenue is less tested than the avenues provided by MSFT for applying the patches.) Actually, if you had to pick one - given that these are likely to be security-related patches, you're probably better off *not* having McAfee and having these patches (as opposed to vice-versa.)
So, how to fix? I don't know if you've tried this already, but I usually use the "windows Update" website (available through the tools menu of IE) to install Microsoft patches. If that doesn't work, I'm not sure what avenue to pursue... Does anybody else have any other suggestions?
Posted by: Ed at December 1, 2006 12:17 PMThanks, Ed. I just got to your reply yesterday. I'll try the Windows update route and let you know what happens.
Posted by: Rev. Frederick Victor Simunich at December 14, 2006 07:38 AMMixed results, Ed. The update started as with the McAfee route: "1, 2, ... 11 of 18 installed ... "'failed!'", but the last five or so "... 'done!'". Then the list of failed installations, most security-related. I these were the same 13 that failed to install earlier.
Posted by: Father Fred at December 15, 2006 07:25 AM