14 DAY TRIAL // In Microsoft's perspective, digital signatures for kernel-mode software are one of the best security mitigations designed to protect the x64 editions of Windows Vist6a from malware, and especially malicious code with rootkit behavior. This is why the company has drastically limited the process of loading unsigned kernel-mode code on x64-based systems. Not even users with administrative privileges will be able to interfere with the security measure. The only, apparently valid, solution is to load drivers coming exclusively from legitimate publishers.
Of course that this is not the case. x64 Vista's mandatory driver signing can be bypassed in numerous ways. Linchpin Labs & OSR recently made available a tool designed to circumvent the security mitigation and load unsigned code into the kernel. The Atsiv tool was associated with legitimate drivers, but permitted the implementation of its own PE loader within the signed kernel driver. "The authors had gone through the process of obtaining a signing key for both the 32-bit and 64-bit versions of Windows Vista for their kernel driver. The result was that it could be used to load arbitrary unsigned driver code including rootkits into the Vista kernel," revealed Ollie Whitehouse, an architect with Symantec's Security Response Advanced Threat Research team.
Microsoft reacted almost immediately, revoked the compromised driver signing certificates and also updated the signatures of Windows Devender in order to recognize the tool as potentially unwanted software. Whitehouse underlined the fact that the simple revocation of the certificate would have done nothing to mitigate the security threat, thus explaining the need for Windows Defender to come into play. Additionally, a reboot of the operating system is necessary in order for the revocation to come in effect and to be integrated into the kernel mode revocation mechanism.
"While not a huge problem on the desktop, as we all shutdown a PCs at some point on a semi-regular basis, it does highlight an interesting issue for Longhorn (Windows Server 2008). Imagine a world where the "bad guys" have got 40 - no make that 400, no actually make that 4,000 - signing keys. They then decide over the course of 10 years to release a slightly different obfuscated version of their malicious code with a different signing key every day," Whitehouse added.
For a corporate environment, and the server side, the issue could represent quite a problem. No business can afford to reboot mission critical server infrastructure on a daily basis just to ensure certificate revocation and its own security. "This is going to be an interesting game of cat and mouse to watch, I also believe Microsoft may have to revisit the subject of dynamic revocation," Whitehouse concluded.