First there was Atsiv, the kernel driver that served as a welcome mat for unsigned and potentially malicious drivers to load into Vista and other Microsoft operating systems.
Then came the ATI driver that could allow arbitrary memory writes to the Vista kernel—a vulnerability that has been introduced to potentially millions of laptops, given that the driver is preinstalled along with Vista.
Now Symantecs Ollie Whitehouse is pointing out yet another driver vulnerability that actually predates those two: WinPcap, an open-source, packet-sniffing driver used by tools such as Wireshark.
WinPcap (Windows Packet Capture Library), which is used for link-layer network access in Windows environments, allows applications to capture and transmit network packets bypassing the protocol stack and provides kernel-level packet filtering, a network statistics engine and support for remote packet capture.
The developers of the widely used driver added support for Windows x64 in January, as its change log shows, “by digitally signing all the binaries of the WinPcap distribution.” Then on July 3, they fixed a bug that involved a system call found on Unix-like systems that allows an application to control or communicate with a device driver outside the usual read/write of data. The bug caused a BSOD (blue screen of death) when passing invalid parameters from the user level.
In Windows NT, 2000, XP, 2003 and yes, Vista, a BSOD happens when the kernel or a driver running in kernel mode cant recover from an error.
As Whitehouse described it, the WinPcap vulnerability allows, yet again, arbitrary writing to kernel memory.
Its another example of a certificate Microsoft will have to consider pulling, Whitehouse said, and its another really good reason to stay on top of upgrades.
At this point, its clear that driver problems are going to occur frequently with Vista. As has been made evident by the Atsiv and ATI driver news and now by this WinPcap case, and as was made abundantly clear by kernel security expert Joanna Rutkowska at Black Hat earlier in August, theres no shortage of vulnerable drivers.
As Whitehouse pointed out when I talked to him Aug. 14, the ability to restrict loading of unsigned drivers into the Vista x64 kernel (its optional in 32-bit but restricted in x64) was supposed to be a good thing, “to stop malicious authors from creating malicious drivers” that they could then use to load rootkits into the Vista kernel, he said at the time.
Was the idea that Vista x64 is more secure due to its policy on unsigned drivers something we all made up?
“I believe driver signing was originally described as a security feature designed to stop the loading of arbitrary kernel drivers,” Whitehouse said in an e-mail Aug. 15. “With the advent of kernel rootkits this was a common method they used to load themselves in the kernel and influence the operating system to hide themselves. KMCS (Kernel Mode Code Signing) should be seen as complementary to KPP (Kernel Patch Protection) in providing the first line of defense to stop from code being loaded. Obviously the discovery of vulnerabilities in legitimate drivers undermines this.”
Fair enough. But if we go by an Aug. 3 posting on Microsofts Windows Vista Security blog and the companys subsequent response to driver issues, we must conclude, however, that we have been mistaken about driver signing being intended as a security feature.
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.
“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.”
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 PatchGuard—which 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 email@example.com.
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.