One of my colleagues, Orlando Padilla,recently ran across a tool by Linchpin Labs & OSR, which allowedunsigned drivers to be loaded on Vista 64-bit. The tool, Atsiv,is interesting since one of the big security features advertised byMicrosoft for Vista 64-bit was the fact that no unsigned code could beloaded into the kernel in order to help mitigate malicious kerneldrivers typically used by rootkits.
When looking at how it did its magic the original .exe contains two resource sections:
These are actually signed 32-bit and 64-bit drivers. The command linetool loads the appropriate driver, which then in turn allows loading ofunsigned drivers due to the implementation of their own PE loader. Aside effect of using their own load is noted by the authors in theirdesign documentation:
“Atsiv doesn’t add the driver to the PsLoadedModuleslist so it is not visible in the standard drivers list.”
This is rootkit-type behavior. In doing a little further research, I stumbled across a posting on rootkit.com by one the authors, who pointed out:
“A signed file uniquely identifies the company thatdeveloped that file, but when companies can be created and registeredin jurisdictions known for protecting the privacy of company foundersand directors, you have to ask what does driver signing actuallyrepresent? Signed drivers can be signed by an arbitrary legallyregistered company. Absent any control over what the driver actually isor does, this provides no real additional security, other than removingauthor anonymity.”
So in order for Microsoft to mitigate the risk of malicious codeutilizing this signed driver to load their own, they are going to haveto revoke the signing certificate. It’ll be interesting to see how longit takes Microsoft to do this. Secondly, as the author points out, allit will take is someone to register another company, obtain anothersigning certificate, and the process will start over again.
Anyway, it will be an interesting time ahead for a process that needs to balance ease of use with its security requirements.