Symantec Report IDs Holes in Vista Kernel Security

While praising many of the tactics that Microsoft has employed to increase kernel-level security in existing iterations of its next-generation Vista operating system, Symantec maintains that a small number of loopholes remain that could leave the product

Anti-virus market leader Symantec has published its third and final report in a series of studies meant to examine the security improvements being made by Microsoft in early versions of its Vista operating system; while lauding the software makers efforts to lock down the kernel of the next-generation Windows OS, the security company did find several shortcomings.

As with Symantecs two previous reports, researchers at the company dissected portions of the beta versions of Vista already shared with the public by Microsoft.

The earlier reports, which studied networking and account privilege management features of Vista, respectively, broadly questioned Microsofts ability to execute some of its security-oriented development efforts.

The third report provides mainly positive feedback for the software giant, but still includes a pair of criticisms.

The latest report hands out praise for much of Microsofts kernel-related work, which includes the addition of driver signing requirements, the companys PatchGaurd anti-patching technology, kernel-mode code integrity checks, optional support for a secure boot mode, and use of restricted user-mode access to a Vista desktops physical memory.

Symantec observed that there is substantial value in the enhancements, which are largely aimed at preventing unsigned code from being injected into the Vista kernel, and establishing a virtual "chain-of-trust" from the time a Vista PC boots until its applications are launched.

On the whole, the changes will improve security of the Vista kernel "significantly" compared to earlier iterations of the OS, according to the report, even when the Microsoft software is compared to products that have long claimed to be more secure than Windows, including Linux systems or Apples Mac OS X.

/zimages/2/28571.gifRead more here about Vista security issues.

However, among the positives identified by Symantec, the research report highlighted a pair of perceived shortcomings which could still leave the Vista kernel at risk if exploited.

In both instances, Symantec researchers pointed out flaws in the driver signing technology that Microsoft has added to the kernel.

The most common mechanism for delivering malicious code into the Windows XP kernel is through a driver, typically installed on an end users machine without his or her knowledge by a Web site or online banner advertisement.

In Vista, all such drivers must be authorized to download via an authorized code signing certificate, which must be provided by a trusted source such as Microsoft or VeriSign.

While the process should eliminate the threat previously posed by malicious drivers aimed at the kernel, as long as Microsoft keeps unauthorized sources from obtaining the certificates, Symantec said that it is possible to disable the driver signing and code integrity capabilities by using binary patches on the operating systems WINLOAD.EXE and CI.DLL files.

The security company said that patching the files at runtime to exploit the issue is quite straightforward, with each file requiring patching at just a single location. And despite the fact that the files are protected by the WRP (Windows Resource Protection), the files can be altered relatively easily, according to the report.

The second issue, revolving around the lack of certificate revocation support in WINLOAD.EXE, can "easily undermine" the advantages of driver signing if the legitimate software publishing certificate of a company is stolen, published or misused by another party, specifically a former or disgruntled employee.

Once the driver signing checks have been disabled, a malicious unsigned driver can be loaded, the researchers said.

However, Symantec pointed out that Microsoft has promised that certificate revocation will be available in the Release Candidate 1 version of the software, due out sometime in early 2007.

Next Page: Responding to reports.