McAfee, Symantec and vested interests

I found this to be an interesting article, as I do find it strange they want to hide the kernel so to speak and I'm really not sure why this guy supports that. It's my opinion that having something open makes it more secure, because more people get a chance to attack it and find ways to fix it.

Is it just me or does anyone see the irony in that Microsoft has had years of lax security that helped create the industry's that help protect those breaches, now late into the game Microsoft comes out with it's Onecare product line. So you have a company that is selling something that is flawed, and now are selling you the product to fix those flaws, anyone see a conflict of interest there?

http://blogs.zdnet.com/carroll/?p=1611&tag=nl.e622

McAfee, Symantec and vested interests Posted by John Carroll @ 9:25 am
Digg This!

Vested interests often force governments to continue with policies that are counter-productive, if not downright negative. Examples aren't hard to find. Even if congress had the will to confront the vested interests that protect all the various deductions in the US tax code and create something that is clean and simple, truckloads of lobbying dollars would be spent by tax preparation companies to block the changes. Mandatory minimum sentencing laws are strongly supported by the private companies that build and maintain many of America's prisons, even as those laws swell America's prison population to levels not typically found in nominally "free" nations. Likewise, the DEA and companies that support them can be expected to fight against any attempts to stop America's futile war on drugs, a war that sends Bolivian leaders into the arms of Hugo Chavez, funds both sides in Colombia's civil war (think Al Capone times 1 million) and provides a steady stream of cash to Afghani insurgents through sale of poppies - the raw material used in heroin.

Though Symantec and McAfee lobbying the EC on behalf of their ability to hook the Windows kernel doesn't wreak as much havoc as these other vested interests, as an instance of business interests using government to warp policy in selfish directions, it falls into the same category. This smells of companies trying to preserve the flaws in a product upon which they have built their businesses. Really, does anyone in these forums WANT third parties to have access to the Windows kernel? The fact that no one does is why McAfee/Symantec aren't trying to defend the inherent value of such access and opt instead for the "futility" argument. The core of the argument is that PatchGuard won't work and that hackers will find workarounds that McAfee will have to ride in and fix for Microsoft. Essentially, there's no point in Microsoft trying to protect the kernel because they will never make it bulletproof, anyway. Following that reasoning to its logical conclusion, Microsoft shouldn't bother to alter its software development processes so as to emphasize secure coding techniques, given that perfection is impossible, and from a business standpoint, deprives Symantec and McAfee of the opportunity to protect consumers from the consequences of those flaws. As noted, I'm not seeing many in ZDNet Talkbacks rushing to defend McAfee and Symantec in their quest, probably because they DON'T WANT Symantec and McAfee to have that kind of access.

If McAfee and Symantec want to do something useful, they should build products that help to to enforce the kernel protections represented by PatchGuard. What they should NOT be doing is trying to prevent Microsoft from locking down the kernel in the first place. People really should read this blog post by Stephen Toulouse, a program manager in Microsoft's Security Technology unit, as it clarifies considerably the situation as it pertains to kernel hooking past, present and future. http://www.stepto.com/default/log/displaylog1.aspx?ID=258

Some useful excerpts…

Regarding Microsoft's past encouragement of kernel hooks: Wrong. For the implementation of the 32 bit kernel of Windows, there existed undocumented and unsupported system hooks into the kernel. Their use was frowned upon, even inside Microsoft. It's simply not a safe practice to utilize these interfaces into the kernel. Regarding the termination of support for kernel hooks being something that is "new:" Wrong.

Kernel Patch Protection was implemented almost 2 years ago in Windows XP x64 edition and Windows Server 2003 x64 edition. Regarding supposed "insecurity" resulting from a ban on kernel hooks: What security vendors are misrepresenting, is that only through unrestricted access to modify the kernel at the highest level of privilege can they protect you.Of course, the referenced blog predates Microsoft's decision to enable in some as of yet undetermined fashion a means by which to enable kernel hooking "in a secure fashion."

On that note, consider the perils of such an approach as explained at the end of Mr. Toulouse's blog. First, you grant one, pretty soon you have to grant thousands. That's how many people are out there using these undocumented, unsupported interfaces into the kernel.

Second, the more exceptions you grant, the more you dilute the protection. Attackers will simply morph their attacks to try and mimic the "safelist" to get an exception – this may be as simple as malicious software “bundling” third party software in order to disable the protection.

Third, because the OS was still designed to be run with the unmodified kernel, you still have the problem of code running at highest possible privilege crashing the system or causing performance problems.

Fourth, by granting an exception list you introduce a huge performance problem into the kernel, as you force it to check a safelist with every single operation.

Fifth, how would the logistics for adding and removing exceptions work? Would it only be done in software updates? Service Packs? Would someone sue because we weren't fast enough implementing them into a safelist?

That last issue is particularly worrisome for Microsoft, and constitutes the problem with selectively allowing people to have access to the kernel. If McAfee and Symantec get access, you can expect most security companies to want comparable access, and once that happens, the question becomes: how big do you have to be to have access? Pandora's box, truly.

Like prison construction companies encouraging policies that lock up as many people as possible (let's not call them prisoners; let's call them "customers"), McAfee and Symantec are trying to encourage an architecture that "needs" the fixes of a McAfee and Symantec. In so doing, they show how self-interest and government controls over software design collide to create "solutions" that have little to do with benefitting consumers.