eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
I think it was around the introduction of Authenticode that Microsoft talked a lot about how security is all about trust: Who do you trust? Who do you not trust? This is a tautology of security: It has to be true in any environment that you have to trust someone—the operating system kernel, for example. And because theyre part of the kernel, some device drivers have to be trusted as well. This is a problem that is difficult to solve.
Authenticode addresses the problem by supporting digital signatures on executable files, including device drivers, and allowing users the opportunity to examine the signature and make a judgment about whether they trust the person or company who signed the file to run code on their system.
Because it requires all new device drivers and programming changes, Microsoft took the opportunity with 64-bit Windows Vista to require that device drivers be signed. Try to load an unsigned driver and you get a big, cant-miss error message.
There have been reports before of holes in the driver-signing requirements. But now theres a tool from Linchpin Labs named Atsiv that allows you to load unsigned drivers in 64-bit Vista. The two keys to how it does this are that it is, itself, a signed 64-bit device driver, and it uses a custom loader for other drivers it loads.
At this point its worth giving a little more detail on the certificates used in driver code signing. Such drivers require their own code-signing certificates from a trusted certificate authority. These cost nontrivial money—at least a couple hundred dollars—and the CA is supposed to do some checks on the authenticity of the applicant, so you cant claim youre IBM and use a stolen credit card to pay for it. There have been some abuses in the past, but clearly you run some risks and encounter obstacles trying to skirt the system. And theres more: 64-bit drivers must be signed by a special cross certificate from Microsoft.
So back to Atsiv. I havent actually tested it myself because I dont have a 64-bit Vista system up. Normally, when you load a 64-bit driver, there is an informational dialog box typical of what users have seen from Authenticode for years. See the example, from a Microsoft white paper.
But there are ways to suppress these dialog boxes, and even if there werent, some users just reflexively say yes to such things. In other words, they are too trusting. So if you run Atsiv you may or may not get such a warning for the driver that is a component of the tool. But you will get a warning from User Account Control: Even if you are logged in as administrator, which is required in order to load drivers, you will get a warning that the operation you are attempting to perform requires elevated privileges. This is your chance—perhaps your last chance—to reflect on what you thought the program did and whether you want to trust it to do dangerous things.
Since certificates are involved, its possible for Microsoft or whoever issued Linchpin Labs certificates to revoke them. Im still trying to find out how often Vista 64 checks for certificate revocation. The worst case is at driver load time, which would be bad, since this system Im writing on hasnt been rebooted since last patch Tuesday. Ill get back to you when I have an answer.
If the cert were to be revoked, any malware installed in this way may be disabled, but its a moot point perhaps. The system is already 0wned, so you cant trust it. In fact, since drivers are kernel code, perhaps they can interfere with certificate revocation checks.
So digital signatures on code are about facilitating trust decisions. They arent a way to stop malicious code; they help you to decide what might be malicious code. Make a bad decision, and you shoot yourself in the foot.
The hole Atsiv abuses may be filled one day, but it shows that the driver signature requirement is one more imperfect mechanism for facilitating trust decisions. Atsiv doesnt fly through without warning. Nothing changes the fact that the most important security device is the one sitting at the keyboard.
Security Center Editor Larry Seltzer has worked in and written about the computer industry since 1983.
More from Larry Seltzer