The Vista "kernel access" controversy - what does DC think?

[JavaJones]

Here's the latest in the month-long controversy surrounding Microsoft's unwillingness to allow 3rd parties (such as antivirus providers) to access the Vista kernel:

McAfee said Wednesday that Microsoft has failed to keep its promises, and has not delivered the necessary code and instructions to access the core of the Windows Vista operating system. Microsoft promised the European Commission it would do so last week.

The company is the second in as many days to claim Microsoft is not providing the APIs needed by its security partners. On Tuesday, Sunbelt Software called the company's announcement about sharing APIs was a "red herring" to fool the press.

http://www.betanews.com/article/McAfee_MS_Failing_to_Provide_Code/1161180764

Now the first time I read about this a few weeks ago my first thought was the same as Microsoft's position - if A/V providers can't access the kernel due to protections, shouldn't that protection be kept in place to prevent issues, not opened up potentially causing them? Sure you could argue there are bound to be vulnerabilities in it, but if the problem is something Symantec can solve with downloadable updates, then it's certainly something MS could solve in the same way. It seems to me then the proper way to deal with this would be for companies like Sunbelt, etc. to report any discovered vulnerabilities to MS for fixing, *not* to force MS to open things up to potentially more issues. Seems like Mcaffee and the rest are just crying over sour grapes. MS takes steps to increase security and it *may* slightly hurt their business model - must we now be mandated to insecurity just to protect a company's "right to profit"? This reminds me of the RIAA.

I did some searching here and didn't see much discussion this issue, but it's something I'm really interested to hear other (non-Betanews - e.g. informed and reasonable ) opinions on. So, thoughts and comments? Is MS in the right here; are Mcaffee and the rest just being bullies to protect their business models? Or is MS just trying to provide false hope of real security and we *need* 3rd parties to go poking around in the kernel to make it truly secure?

- Oshyan

[Carol Haynes]

I've deleted the email so I haven't got the link but there was a news announcement today that MS have now started distributing the APIs to security companies.

[f0dder]

There's two levels to this.

One is allowing unsigned drivers - which is bad enough; several of sysinternals tools need drivers to run, and the malware authors will find ways to bypass this anyway.

The next level is the "patchguard" system or whatever it's called, which will hang the system if certain kernel mode structures are modified. Yes, malware tends to modify these structures, but so does antivirus and firewall software, and stuff like sysinternals filemon/regmon.

Obviously the bad guys will, once again, find a way to bypass patchguard, while legitimate users will be hurt.

Abandon ship, abandon ship...

[NeilS]

There's obviously a certain amount of self-preservation going on here on the part of the various security vendors, but there's also more than an element of truth to what they are saying.

When it comes to security, choice is pretty critical. Part of this choice simply comes down to who you trust (and I'm sure plenty of people are understandably wary of trusting MS that much), and a large part of it comes down to how you want the security measures on your system to manifest themselves.

For example, the average Windows user isn't going to want their system so locked down that everything they do causes a security dialog to pop up. In fact, the average user won't know what many of the dialogs mean. So they typically want security which does a decent job with minimal user interaction.

More discerning/paranoid users might want increased security, and won't mind paying the extra cost in terms of effort required to train/tune the system to be as secure as possible.

By locking security vendors out of the kernel, MS would be effectively removing the user's choice of security system. Although MS could conceivably provide a security system which caters for most people pretty well, they'll never cover everyone and, to be honest, covering "most people" has never been their strong suit either.

Anyway, it sounds like they might be backtracking already, but even if they aren't, it's likely that they will at some point. It wouldn't be the first time.

[JavaJones]

Er, ok yes they'll find a way to bypass, but is it better to provide an actual API to do so (that ostensibly only A/V companies have access to, but yeah right!), just so the few A/V companies that are complaining about this can do as they please? The likelihood is *someone* will have to patch this. MS is already comitted to monthly security updates, so it is certainly likely they would be able to provide a patch for any discovered vulnerabilties. Maybe not quite as fast as the A/V companies, but it's arguable the holes would be smaller and less visible without such API's available.

I dunno, the whole thing just seems suspicious. I'm not so much interested in whether MS comply but in talking about whether they *should*. Perhaps none of us know enough about this to comment with authority, but I do note that the few companies who have officially complained are some of the ones I respect *least* in the field of security. Mcaffee and Symantec in particular are pretty far down on my list of security products to recommend. Meanwhile on the other side, companies who explicitly say this is *not* necessary, you have Sophos and Kaspersky Labs (I think), two of the more well-respected and still reliable companies, but also perhaps not coincidentally two of the smaller ones (well behind Symantec and Mcaffee anyway). So it seems to me there is more going on here than it appears, at least on the face of these company's requests.

Neil: Locking people out of the kernel is a pretty low-level security measure to protect against a relatively few very specific attacks. Most viruses *do not* alter the kernel at present, and A/V providers shouldn't necessarily have to either. MS already said they would allow companies to replace their warnings and whatnot with their own version - that seems to be enough to satisfy the needs you outline (which I agree are very legitimate). All I can really say to that in closing is that from what I've seen 3rd party companies have historically always been responsible for *complicating* the security and protection scenarious, not simplifying them (albeit they do generally provide more protection than MS's defaults). So I'm not sure I really see your point. I agree that is basically what these companies are arguing, but I'm just not convinced at all that they need this level of access to provide their services adequately.

- Oshyan

[NeilS]

Locking people out of the kernel is a pretty low-level security measure to protect against a relatively few very specific attacks. Most viruses *do not* alter the kernel at present, and A/V providers shouldn't necessarily have to either. MS already said they would allow companies to replace their warnings and whatnot with their own version - that seems to be enough to satisfy the needs you outline (which I agree are very legitimate). All I can really say to that in closing is that from what I've seen 3rd party companies have historically always been responsible for *complicating* the security and protection scenarious, not simplifying them (albeit they do generally provide more protection than MS's defaults). So I'm not sure I really see your point. I agree that is basically what these companies are arguing, but I'm just not convinced at all that they need this level of access to provide their services adequately.

The fact that most viruses don't alter the kernel "at present" doesn't strike me as a useful security policy. When/if they do start doing this, how are the security vendors supposed to respond? Or should they just rely on MS to patch the hole sometime in the next month? What do they tell their customers in the meantime?

I also don't think the argument is just about AV protection. It sounds like some of the complete security suites have "legitimate" reasons for patching the kernel themselves, so that they can hook various things to provide extra forms of protection. OK, so maybe binary kernel patching isn't a great idea, and possibly even dangerous if achieved via false assumptions, but this just tells me that MS should be opening up the kernel for a more legit form of patching as well as locking it down against unauthorised modifications.

(Slight caveat to the above: I have no idea if any of the security vendors have actual legitimate reasons for needing to patch the kernel, so you could be right that none of them really need access. I'm pretty sure that legitimate reasons could exist, but that's not the same thing of course. )

[f0dder]

On this system, Kaspersky has around 37 kernel hooks, and daemon-tools 3.47 has two (could be more, if it hooked some functions which kaspersky subsequently re-hooked). Kernel hooks are one of the things Microsoft is stoping (or trying to stop - the bad guys will always find a workaround) with Vista. Check http://www.resplendence.com/hookanalyzer .

Stopping unsigned drivers is also bad, imho. As I already mentioned, legitimate programs like some sysinternals software (regmon, filemon) need drivers to work. By only allowing signed drivers, Microsoft makes sure only companies that has a whole bunch of cash and a relatively high profile will be able to do drivers... no more sysinternals-like startups. And again, the malware authors will find a way around this.

[Carol Haynes]

Looks like another reason to avoid Vista - and another example of the MS cash cow in action. It really isn't practical for many small firms to produce certified drivers for their products.

It strikes me that the net effect of Vista will be the beginning of a whole new round of anti-monopoly lawsuits because they are:

1) Trying to cut out the need for security firms by providing the services themselves,
2) Putting many small businesses at risk with the drivers issue
3) Putting hardware manufacturers generally at risk with the restrictive EULA - I'd guess many people will be reluctant to spend lots of cash on hardware once they have VISTA installed in case MS then consider their machine a new device!
4) Challenge software writers with the restrictions imposed by VISTA on what is possible (like eg. not being able to burn ISO files in VISTA).

[f0dder]

Another point of concern:

With late model Pentium4 and AMD64 machines, Virtualization stuff was introduced (pacifica and whatever other codenames). This can be abused by malware, so basically OSes need to be updated to be eiter hypervisor-based, or to turn off the feature (which can't be software-enabled without a CPU reset - nice thinking from intel and AMD ).

Problem is? Well, I dunno how big a company you need to be or how much cash you need... but it takes something to be able to use HyperVisor technology under Vista. Quite affordable for VMWare I bet, but for smaller developers? Not likely. And again, malware authors won't care about licensing. Of couse breaking a hypervised machine is supposed to be difficult, but it will be doable in one way or another.

[JavaJones]

Lots of good, interesting points here. I think we're getting a bit off track with the discussions of signed drivers, etc. but those *are* very important considerations and additional factors in the overall Vista picture.

I agree with the majority of you that the signed driver requirement is a bad thing, especially for small companies, as long as the actual verification process is still costly. But I say don't allow unsigned drivers necessarily (or if you do so, make it really a pain in the butt), rather just make the verification process cheaper. OR perhaps better yet provide 2 levels or types of verification - 1 security-related and 1 stability/functionality related (the latter being the major focus of the current verification as far as I know). This allows drivers to be made that make no guarantee of *stability*, but can at least be verified as not being a *security risk*. I would think such a verification process would be much less rigorous and thus costly because it is much less system-dependent. You can analyze a given driver and test on a limited subset of machines and generally see if it poses a security problem, whereas testing on a wide variety of hardware is much more important for stability and compatibility verification.

Anyway I'd like to get back to the "access the Vista kernel" thing though (continue discussion about driver signing, etc. if you want of course - maybe fork the thread if necessary). Neil, I'd be a lot less suspicious of this from the A/V vendor side if there were more unanimous outcry about it, and if the firms I actually respect had a problem with it. But as is, like I said, it's mostly the firms I don't like and who I think make poor products anyway (that don't protect that well *as it is*) that are crying for this level of access. Frankly I don't want Mcafee or Symantic digging around in my kernel! The problem is you can't just allow access to only them, either. It has to be basically opened up for anyone with "the right credentials" to access. That seems like a huge and unnecessary hole to me.

As for legitimate reasons, you speculate they have some, but I've not heard of any. I'm no expert, but from where I stand MS's arguments make at least as much sense as the A/V vendors - IMO a good deal more in fact. The only thing that gives me pause about it is MS caving so quickly, but I think the antitrust stuff, especially in the EU, is playing heavily into that, so the picture is not entirely clear without that taken into account.

Ultimately I guess the question is "Will this make users of Vista more secure overall?" and I honestly don't feel confident that the answer is yes.

- Oshyan

[mouser]

I guess from MS perspective, they are probably tired of getting a bad rap for instability when it's caused by 3rd party drivers and software.. if their motivation is to reduce the # of crashes and instabilities by making it harder for companies to polute the kernel, it's somewhat understandable.

[f0dder]

JavaJones: perhaps only a couple of the lame companies have bitched about the kernel hooking stuff, but check your product of choice with http://www.resplendence.com/hookanalyzer . Kaspersky 6.x has 37 hooks... you need to hook stuff if you want a transparent scanner.

And as for driver signing, money is one issue, the time it takes to verify is another... and the third: Microsoft will decide which drivers they like and which they don't. I wonder if they like daemon-tools and similar...

[NeilS]

Neil, I'd be a lot less suspicious of this from the A/V vendor side if there were more unanimous outcry about it, and if the firms I actually respect had a problem with it. But as is, like I said, it's mostly the firms I don't like and who I think make poor products anyway (that don't protect that well *as it is*) that are crying for this level of access. Frankly I don't want Mcafee or Symantic digging around in my kernel! The problem is you can't just allow access to only them, either. It has to be basically opened up for anyone with "the right credentials" to access. That seems like a huge and unnecessary hole to me.

Yes, I would agree that the companies making these claims don't fill me with confidence that the claims are entirely valid. Then again, just because I don't rate them as highly as Kaspersky or ESET, that doesn't mean that their claims are invalid either.

As for opening up the kernel for modifications, there's no reason why this should have to cause a hole. First off, the kernel can ask the user if he wants to allow a modification, much like a firewall will ask before authorising outbound traffic. If this isn't deemed secure enough (e.g. an attacking program might just click the "yes" button for you), then they could easily require that kernel mods are done during a reboot, where the user is asked in a much more controlled environment (i.e. only the kernel is running).

As for legitimate reasons, you speculate they have some, but I've not heard of any. I'm no expert, but from where I stand MS's arguments make at least as much sense as the A/V vendors - IMO a good deal more in fact. The only thing that gives me pause about it is MS caving so quickly, but I think the antitrust stuff, especially in the EU, is playing heavily into that, so the picture is not entirely clear without that taken into account.

I'm not entirely convinced that MS's arguments do make more sense. One of their main arguments seems to be that kernel patches can be unstable, and extrapolate from this that kernel patching in general is a bad thing. This is FUD, basically, and I would be more inclined to believe them if they stayed away from this line of argument.

Coming back to what I was saying above, MS also say that there is no way to tell if a kernel patch is coming from a legitimate program or a piece of malware. Of course you can tell - you limit kernel patching such that it can only occur in an environment where you can ask the user unambiguously if they want to allow the patch or not. They might argue that you can't trust the user to know whether to say yes or no, but if this were true, then the whole notion of outbound checking firewalls goes out the window, because they rely on the same kind of mechanism.

The other thing which is slightly concerning is how much of this is down to MS trying to lock down the DRM media route in the OS. If this is a large part of it (and some people seem to think it is), then this would also cause me to question the real agenda behind this stuff.

[Carol Haynes]

I can't help feeling that MS has more than one agenda too.

Re. AV companies - it might be simply that Symantec and MacAfee have sufficient international financial clout to whinge effectively. Other smaller players may be suffering too but just leaving it up to the bigger players to make the running with anti-trust threats. How much notice is MS going to take of Kapersky or ESET taking them to court (MS probably wouldn't care about the Russian market/courts anyway and ESET is too much of a geek AV company to pose any sort of real financial threat).

[JavaJones]

F0dder, just because kernel hooks are needed/used now doesn't mean they will be in Vista. It's a pretty significantly changed architecture, as far as I understand. The need for kernel hooks I would say is something of a kludge, to make up for previous OS's lacking in terms of kernel protection, etc. MS didn't do a proper job of it so A/V companies needed to. There's been no clear indication of exactly *why* anyone needs access to the kernel, provided they are given API's to perform the functions they need (which MS now says they will do for SP1).

Note also that according to what I've read MS's OneCare is subject to the same limitations - i.e. it can't access the kernel directly either. Of course they built the underlying systems so they could build whatever they want into it, but the point is that those protections are separate from OneCare and OneCare doesn't need to work with or interfere with them to do its job.

As far as the driver signing, I agree with you again. It'll never happen but I think the verification should be done by a 3rd party and, as I said before, have different levels or types of verification.

It seems to me like a lot of misinformation has been spread by both sides. It's hard to tell whether A/V companies are full of crap, or MS, or both (probably both). But MS seems pretty emphatic in the latest news that they have been misrepresented and misquoted, etc. So that's interesting.

Carol, other A/V companies have specifically come out and said they do *not* need such access. It's not just that they're keeping quiet.

Anyway, I wonder why these companies aren't shouting at Apple for not having more vulnerabilities in OS X. I mean clearly Mcafee is losing revenue from all the Mac people who don't need to buy their products.

The saga continues!

- Oshyan

[f0dder]

The current way of requiring kernel hooks might be a kludge, but it works well. The Vista kernel is probably a bit different etc., but you'll need some way of hooking specific functions, or inserting "filters" for them. If I know Microsoft and how they usually do stuff, they might make some half-reasonable API, but will forget a bunch of important ones.

Carol, other A/V companies have specifically come out and said they do *not* need such access. It's not just that they're keeping quiet.

Any protection not doing on-demand (or whatever the "real-time" stuff is called) won't need hooking. Others will - or at the very least need to insert filter drivers.

[JavaJones]

I thought pretty much all A/V soft had "real-time" protection these days. It seems to me like filter drivers aren't being restricted (although admittedly we don't have enough info really), so that should still be an option. And MS is saying they will be including security vendors in design of the security API. So we'll just have to see how that turns out.

I agree there are a lot of problems here, but I think they're on both sides of the equation, and I'm not so sure - in this particular instance - that MS is really in the wrong. That's not to say I'm happy about much else with Vista, lol. But I do think it's a good thing they're trying to secure the kernel better!

- Oshyan

[mwb1100]

And as for driver signing, money is one issue, the time it takes to verify is another... and the third: Microsoft will decide which drivers they like and which they don't. I wonder if they like daemon-tools and similar...

There are different levels of driver signing, and different platforms have different requirements.  On x86 platforms, driver signing is not required.  On Vista x64 platforms, drivers must be signed, but they do not have to be fully 'Windows Certified". Any developer can sign a driver with an Authenticode certificate from one of 3 vendors- Equifax, Verisgn, or Geotrust (soon to be 2 vendors, since Verisign is buying GeoTrust).  The driver does not have to be submitted to anyone for testing or validation.

The signing is simply a method of verifying non-tampering and providing a traceable path to the creator of the driver.

However, the Authenticode certs do cost $200-$400, so while this scheme is not a big financial burden even for small commercial developers, it does pose a huge problem for open source, educational, and hobbyist driver development.

Oh, and it does create some pain in the actual process of developing and testing the software.

[f0dder]

mwb1100: thanks for the info (could you provide some MS link for this info?) - sounds like less of a pain than I thought it would be. But $200-400 is still a fair amount of money if you want to create freeware tools... and there might still be some requirements for the people who want to get a cert?

[JavaJones]

Interesting info indeed. I agree with f0dder, would love to see sources of additional info on this as it's a potentially thorny issue. And of course if putting up money is all that's required how much of a safety measure is it?

- Oshyan

[JavaJones]

More news today - direct word from Sophos "we don't need MS to open up patchguard" and Mcafee "Vista is less secure than XP" respectively. I have to say, even though the Mcafee article sounds like mostly FUD, Sophos also sounds kind of full of it.

- Oshyan

[mwb1100]

Yeah, I should have put some links... This is a topic that has been confusing even to seasoned driver writers.  For the most-part, I think it's a good idea, as it will reduce the possibility of rootkits in the long run (64-bit OS's only for now), but I think that it does not adequately address the needs of non-commercial driver authors.

One of the few docs from Microsoft that makes it clear that Windows Certification is not necessary to sign a driver for Vista 64:

Digital Signatures for Kernel Mode...:  http://www.microsoft.com/whdc/system/platform/64bit/kmsigning.mspx

It has a table that indicates the requirements for havng a driver loaded on Vista 64 ("Options for signing kernel modules").  Following that table is this paragraph:

Kernel Mode Code Signing using a SPC provides identifiability of the publisher of a kernel module loading into Windows Vista. It does not provide any level of certification of functionality or reliability of the kernel module. For drivers that do not qualify for the Windows logo, or the Windows Logo is not one of the product requirements, the publisher can create a .cat file for the driver package and sign it with the publisher’s SPC

Kernel Mode Signing Walkthrough:  http://www.microsoft.com/whdc/winlogo/drvsign/kmcs_walkthrough.mspx

Cross Certs for Vista Driver Signing:  http://www.microsoft.com/whdc/winlogo/drvsign/crosscert.mspx

(note that while MS lists 6 different CA certs they approve for signing drivers, those are all now owned by either Equifax or Verisign)

[JavaJones]

Ooo, interesting "new" articles on this, with some tasty quotes.

Vista RC2 vs. pagefile attack (and some thoughts about Patch Guard)

However, by ensuring that legal applications do not introduce rootkit-like tricks, PG makes it easier and more effective to create robust malware detection tools.

I spent a few years developing various rootkit detection tools and one of the biggest problems I came across was how to distinguish between a hooking introduced by a real malware and... a hooking introduced by some A/V products like personal firewalls and Host IDS/IPS programs. Many of the well known A/V products do use exactly the same hooking techniques as some popular malware, like rootkits! This is not good, not only because it may have potential impact on system stability, but, and this is the most important thing IMO, it confuses malware detection tools.

Patch Guard, the technology introduced in 64 bit versions of Windows XP and 2003 (yes, PG is not a new thing in Vista!) is a radical, but probably the only one, way to force software vendors to not use undocumented hooking in their products. Needles to say, there are other, documented ways to implement e.g. a personal firewall or an A/V monitor, without using those undocumented hooking techniques.

Bypassing PatchGuard on Windows x64

Good stuff!

- Oshyan