Linchpin Labs recently released a tool called Atsiv that provided the functionality to load unsigned drivers on Microsoft operating systems, including Microsoft Vista. Atsiv was born as a research project to examine what enforced driver signing does, or does not, achieve. It was intended to increase public awareness that driver signing as currently implemented does not provide additional security. A company was created and signing certificate acquired within a very short period of time at a low cost, which raises the question as to what driver signing actually represents?
The project evolved to be a free utility. It assists users of Microsoft Vista that are currently unable to use legacy hardware without signed drivers, and casual developers (such as hobbyists) that are not able to use a company's signing certificate. Given the relative ease with which a signing certificate can be acquired, vendors that do not sign their drivers are as much to blame as Microsoft for not satisfying the support needs of consumers. However, with Atsiv, consumers could once again make use of their legacy hardware, actually increasing the user experience of Microsoft Windows Vista.
Microsoft, however, did not see it this way.
On August 3rd, Microsoft employee Scott Field revealed that
Microsoft has classified Atsiv as malware, and have taken the following actions, from the aforementioned link:
- Windows Defender released a signature update on August 2, 2007 that allows detection, blocking, and removal of the current Atsiv driver. Classification of the Atsiv software was done in accordance with the objective criteria used by the Windows Defender team to assess the characteristics of potentially unwanted software.
- Certificate revocation has occurred as of August 2, 2007. Microsoft has worked with partners in the code signing certification authority ecosystem to assess the Atsiv issue. VeriSign has revoked the code signing key used to sign the Atsiv kernel driver, which means the code signing key will no longer be considered valid.
- The security team at Microsoft is investigating adding the revoked key to the kernel mode code signing revocation list, as an additional defense in depth measure. The kernel mode revocation mechanism requires a system reboot in order for the new revocation list to take effect, which is consistent with other Microsoft updates which require and subsequently trigger a reboot.
NOTE: As a new company, DENWP ATSIV INC, was created specifically for the Atsiv research project, the revoked code signing key is limited to Atsiv. All other tools and utilities released by Linchpin Labs do not use this revoked certificate.
Microsoft's actions aren't surprising, but classifying Atsiv as malware is something that we at Linchpin Labs do not agree with. Atsiv does not threaten the user, nor does it provide anonymity to the client drivers that it is used to load. In fact, there is a command to list the drivers that Atsiv loads. Atsiv does not insert the driver into the PsLoadedModulesList because the lock that protects that list is not exported, meaning access is not 100% safe. If Atsiv did add a record to the PsLoadedModulesList, the benefit of this is debatable given that the first thing a client driver could do is remove the record from this list from its DriverEntry routine. Atsiv was intentionally designed to not support automatic loading of drivers, forcing the user to load client drivers manually (assuming he/she had Administrator privileges to start Atsiv) by issuing commands to the Atsiv program interactively. Microsoft employee Scott Field has even admitted that there is no security threat from Atsiv itself, as "Installing the Atsiv driver requires administrative privileges, so there is no security vulnerability related to the default case in Windows Vista where users run with limited permissions through the User Account Control feature". Those who choose to disable UAC have already made the decision to accept a lower security posture.
Scott Field applauds the steps that Microsoft took, as they "were able to identify this issue and respond on multiple fronts, both with help from our partner VeriSign and with new signatures for Windows Defender". Congratulations, you identified an advertised product that behaves as advertised. But we ask, what is Microsoft doing to protect the consumer from actual malicious software for which Microsoft does not have a signature? What about signed drivers that contain exploitable vulnerabilities? What about drivers signed and supported by the malware industry? It is important to note that to prevent Atsiv clones from being produced by the malware industry, the Atsiv source was never made publicly available.
If Microsoft is that concerned about malware, perhaps Microsoft should examine the software it provides free for download, an example being
SysInternals' PsTools package. Recall that
SysInternals was purchased by Microsoft in July of last year. The PsTools package contains command line utilities that could potentially be used by malware for system compromise with Administrator credentials. Do these tools have Microsoft Defender signatures? Obviously not, and we don't honestly believe that any of SysInternals tools should be considered malware. But the fact Microsoft has taken it upon itself to revoke the Atsiv certificate based on its own definition for malware sets a concerning precedent, one that should not be ignored. What if anti-SRE software from company X incorporates a stealth service to help protect products? What if security software from company Y requires that PatchGuard be temporarily disabled for a security related operation? What if software from company Z implements a system for injecting and running Linux drivers in the Windows kernel? The long-term impact of this decision by Microsoft will be interesting, as denial-of-service of legitimate software, justified by an arbitrary definition of malware and subjectively enforced, raises the question of anti-trust violations.
How does Microsoft's decision affect Atsiv? By adding signatures to Microsoft Defender, it should in theory detect Atsiv and depending on how one has configured Microsoft Defender, either automatically quarantine Atsiv or give the user the choice to do so. This means that people should be able to retain the choice to use Atsiv if they choose to. Revoking the Atsiv signing certificate limits future releases of Atsiv (in some respects), and as mentioned above, sets a frightening tone for the software industry. If Microsoft chooses to add the Atsiv key to the kernel mode code signing revocation list, then any version of Atsiv signed with the DENWP ATSIV INC certificate will be prevented from loading, regardless of a user's choice.
Lastly, Linchpin Labs would like to thank the many people who have provided feedback and support for Atsiv. We are happy you found Atsiv to be a useful utility. Unfortunately, Linchpin Labs will not be acquiring a new certificate to support Atsiv, as Microsoft would undoubtedly push to revoke it as well, but we hope the discussion continues. Linchpin Labs would like to suggest that Microsoft spend less time using debatable policy as a security mechanism, and spend more time actually tightening its operating systems. For the casual reader, we encourage awareness of the difference between solid security and a powerful marketing campaign.