The Maginot Line in 1944
“If you entrench yourself behind strong fortifications, you compel the enemy to seek a solution elsewhere.” — von Clausewitz
“Fixed fortifications are monuments to the stupidity of man.” — Patton
Before I start on one of my typical diatribes, I think it’s worthy to note that one of the problems facing the security industry is entrenched user resentment.
I see this all the time: When I write about the larger security vendors, there is almost an angry mob mentality about how they deserve it because “antivirus companies have been soaking us for years”, etc. Ok, so there may be validity to some of that entrenched resentment, but the PatchGuard issue affects all security vendors.
Yesterday, Sophos tapped into that angry mob user resentment in a brilliant PR move — after having drunk the Microsoft KoolAid from a fire hydrant, they openly embraced PatchGuard. In one fell swoop, they positionoing themselves as Microsoft-friendly, happy-dancing, API-loving people. At the same time, they positioned the rest of the industry as a bunch of moronic crybabies. Beautiful.
Now, the Sophos folks are very smart both PR-wise and technically, and so one must give pause to consider their statements. However, I suggest we dig a little deeper.
It is an evolved theory of both security and warfare that one cannot create one defense that is all-encompassing. A infamous object lesson in this thinking is the French, with their Maginot Line: Created to stop a German invasion by land, the German’s merely flew over it — quite a wake-up call for the Frenchies. Now, military planners rely on flexibility as the ultimate defense.
The security industry has had several such lessons, the Code Red Worm being one of them. A network-based worm that utilized a vulnerability in Microsoft’s IIS, it never hit the disk. Instead, it ran solely in memory. A system based on file-based protection would not have been able to stop it.
The lesson? We cannot predict how malware authors will work in the future, and that is one reason why PatchGuard is such a potentially dangerous technology.
PatchGuard creates a barrier to the kernel, against which security vendors (the major defensive bulwark for Microsoft) can’t get in to to help the operating system against an attack, at least without permission through APIs.
Mikhail Penkovsky at Agnitum also points out that the API model itself opens up the kernel to attack anyway.
Why is it so risky to use KPP [PatchGuard] to provide kernel security for computers running Vista x64 rather than a third-party security solution?
Here’s an analogy. Today, every house has a different lock on its front door; in the same way, you can use any security product you want to protect your computer. Now imagine if every house in your city were required to use the exact same lock on its front door. As soon as a burglar figures out how to crack that lock, he can freely enter and steal from any house. This is what 64-bit Windows security will look like with PatchGuard.
His point is valid, because PatchGuard will get hacked in a number of ways: a) through good old-fashioned hacking (like we saw at BlackHat recently), b) or even possibly bundling themselves with a component of a product that does have access to the APIs.
But there’s another key issue: The ability of security companies to fully support the 64–bit Windows platform itself, a fact that Gartner’s Neil McDonald recently highlighted in his warning that if enterprises use HIPS technology, they should postpone deployment of Vista. After all, the APIs won’t even be available until 2008!
And it’s interesting that Neil used HIPS as an example.
HIPS (which stands for Host Intrusion Prevention System), uses methods at the kernel to prevent certain types of attacks. HIPS is part of our Kerio line and it’s also part of other products out in the market. For example, our HIPS functionality helps protect against buffer overflow attacks, by watching for system functions being called from memory locations where they shouldn’t be called. As another example, our Kerio Server Firewall uses HIPS to provide application lockdown.
Sophos and Kaspersky have gone on the record that they don’t really care much about PatchGuard, but that is ostensibly because a) they don’t have HIPS or b) they are not using the kernel in such a way that PatchGuard poses a problem for them. Is this just whistling past the graveyard?
McAfee, Symantec and other companies, like Sunbelt, need this access. For Symantec, it’s around a number of technologies they’ve implemented at the kernel, including Tamper Protection, which prevents hackers from attacking Symantec products themselves. For us, it’s around HIPS, but it could also affect other technologies that we are developing.
Could we use the existing APIs to do what we need to do? Yes, and Microsoft has publicly stated that they will release APIs to PatchGuard to security developers, but a) these will not be for some time (2008) and b) if we need a new API or some enhancement to an existing API, we have to ask for it. It puts security providers in a tenuous position, waiting for possibly up to a year to get the legal APIs to fix a threat that may be in the wild. And waiting for the PatchGuard APIs will delay our ability to ship a 64–bit version of our Kerio firewall and possibly other technologies.
Getting back to the Maginot Line example, however, if some type of new threat comes out that requires a security vendor to access the kernel to protect against it, we’ll all be in trouble, and so will the customer. Because we’ll have to ask Microsoft for an API to the kernel and hope they provide it, instead of just quickly adding some extra functionality to our products by directly accessing the kernel.
Alex Eckelberry