After an in-depth analysis of the new security measures introduced by Microsoft under the name Kernel Patch Protection, the computer security experts at Agnitum claim that this attempt to improve security is possibly more of a move to preclude or block the use of third-party security software in Windows.
Agnitum also believes that Kernel Patch Protection will make it harder for third-party security software vendors to maintain compatibility with Windows, while posing little or no threat to hackers.
Key conclusions from the analysis include:
Kernel Patch Protection is intended to provide better protection for low-level system activities such as the file and registry operations of the Windows kernel, the deepest level of OS operations. Any program that gains access to the kernel can, for instance, hide a folder on the hard disk and make it impossible to delete that folder using regular Windows tools. While malicious programs can modify the Windows kernel and hide themselves in this way to surreptitiously steal information, security software developers also need access to the kernel to provide PC security.
Forcing independent software developers down the road of acting like hackers gives the advantage to hackers, as they dont need to undertake the level of compatibility testing and quality assurance required by legitimate software developers.
The full analysis is available on the Agnitum website: Kernel Patch Protection analysis (link below).
"Microsoft made a logical move with this attempt to protect Windows against rootkits, said Mikhail Penkovsky, vice president of Sales and Marketing at Agnitum, Unfortunately, it doesnt really resolve the problem, and also makes it a great deal more difficult for independent security software developers to be fully compatible with Windows. Nobody knows if Microsoft has done this intentionally, but we cant avoid the suspicion that this move may have been designed to force users to rely on Microsoft and only Microsoft for Windows security. If past experience is anything to go by, third-party security software solutions are likely to be more robust and provide better protection for users, who will be the biggest losers if this proves to be the case.
In 64-bit versions of Windows and in the upcoming Windows Vista, kernel patch protection will insulate the kernel from legitimate changes. This means that no third party security software vendor will be able to install security software that uses kernel functions using legitimate coding approaches, but hackers can still feel free to reverse-engineer their way to successful rootkit delivery using less-legitimate methods.
The problem lies in fact that these less-legitimate methods will work only for specific Windows kernel versions, said Penkovsky. If legitimate independent software developers are forced to take this approach, with every serious update to the OS, those developers will have to make changes to their installation methods. It will be a nightmare for legitimate developers while posing little or no problem for hackers, who dont have to maintain 100 per cent compatibility. And improvements to malware are much easier to code than improvements to security software.
[This is no simple issue and there really is no simple answer. It is easy to raise the criticism against Microsoft that this is simply a shrewd business move and an attempt to extend their monopoly by the usual means, but through different tools - in effect repeating what the company has been convicted of before.
That point of view, however, would be overly simplistic. How to protect the kernel of an operating system from subversion is not a trivial issue. You can take the sledgehammer approach that Microsoft seems to have opted for - if it moves, kill it. And to make sure it doesn't start to move again, better nuke the environment as well (maybe they have learned from observing US foreign policies). This is the easiest approach, especially if you can root it in hardware such as TCPA (or whatever it is called today), which I assume is the longer-term plan. Doing that will remove some of Agnitum's criticism because it will make it way more difficult to circumvent than a software-only solution. This may not, however, be the best security solution as pointed out.
A more difficult solution would be e.g. to extend an ActiveX type certification to comprise installers that modify the kernel, in effect defining a group of "authorised Windows kernel modifiers", companies that can be trusted to make kernel modifications with Microsoft's blessing.
A third solution would be to establish some kernel hooks deeply enough for third-party security software to hook into, probably in the software that handles interrupts on that level. That would require Microsoft to establish a certification programme of some sort, a process not unknown to the corporation.
There are even more ways to skin this particular cat but this is enough to make the point. I can't say that I blame Microsoft for taking the sledgehammer approach - after all, it often takes all the flak when third parties muck up Windows with badly designed software, something that must have cost the corporation millions over the years. On the other hand, this may not be the best solution, politically or technically. Solution three above is better for obvious reasons. I think Microsoft should assume the attitude that it locks the deepest core of the kernel, and establish a third-party vendor programme allowing vendors qualifying in the programme to make kernel modifications above the locked level, but deeply enough to be effective. Any modifications must be certified by Microsoft to fall within the speed and stability requirements Microsoft imposes on its own similar solutions.
Taking that path will kill several birds with one stone:
Related links: (Open in a new window.)
www.microsoft.com/whdc/driver/kernel/64bitpatch_FAQ.mspx
www.agnitum.com/r/kernel/patching/
Taken from Information Security Bulletin.