The KMCS "is a not a security boundary, rather, it is only one aspect of a defense-in-depth approach to security," wrote Scott Field on the Vista security blog. "KMCS does not provide a means [by which] to determine the intent of the signed code (i.e., good or bad); indeed, signed code may contain bugs, be of poor quality, or may be malicious in nature." In fact, Microsoft said, the point of KMCS is to provide a way to track down the author of cruddy code, not to stop malicious code from getting into the kernel.And although some reporters have conjectured that last weeks KPP (supposedly) non-security-related update was actually an on-the-sly move to harden the kernel against drivers introducing malware, Microsoft is holding fast to its premise that the update was yet another defense-in-depth change to build in additional checks for better reliability, performance and resiliency for x64-based Windows systems. "Kernel Patch Protection protects code and critical structures in the Windows kernel from modification by unknown software or data," a Microsoft spokesperson said. "This update is a defense-in-depth change that builds additional checks into KPP for increased reliability, performance and security. Although the update will enhance security within the kernel, this is not a vulnerability-related issue." Protecting the kernel from modification: That sounds rational. That sounds like it could be a push toward the systemic approach thats needed, as opposed to these one-off tackles of wayward drivers and one-off signature revocations. But as Microsoft says itself, those updates arent vulnerability-related, so they arent bad-driver-related At this point, Whitehouse said in an e-mail, Microsoft could start performing code reviews of all drivers wishing to be signed for potential security vulnerabilities. But in reality, thats "not scalable and even then it would become a game of cat and mouse with regards to individuals with malicious intent, determined to get code through the review process," he said. But is beefing up KPP sufficient? "What Microsoft can do (
may have done in the recent update ) is reduce the attack surface of the kernel by beefing up PatchGuard (KPP) protection to minimize the impact of obtaining access to the kernel," Whitehouse said. "However, this in itself is a game of cat and mouse, as its all in software, so an attacker needs to locate the appropriate functionality in order to target/disable PatchGuardwhich is not impossible, just an involved amount of reverse engineering."
My colleague Joe Wilcox summed up the reasons behind Microsoft moving the graphics subsystem into the kernel to begin with in Windows NT 4, swapping graphics performance for a kernel-write problem. His opinion: Nothing should write to the kernel, or as little as possible.
Going by recent events surrounding these bad drivers, maybe hes got a point.
What do you think? Write to me at firstname.lastname@example.org.
eWEEK Senior Security Editor Lisa Vaas has written about technology since 1997.
Check out eWEEK.coms Security Center for the latest security news, reviews and analysis. And for insights on security coverage around the Web, take a look at eWEEKs Security Watch blog.
"Identifying the source and ownership of code that is loaded by the kernel is a fundamental component of the operating system and overall ecosystem trust model," Field said. "Furthermore, this also provides better transparency to the end user in terms of origin of code that is installed and running on a system."