x64 Driver Signing Update


Hi,  it’s Scott Field, Windows Security Architect, again.  Microsoft recently became aware of a third party kernel mode driver named “Atsiv” which provides a deliberate means of loading code that conflicts with the Kernel Mode Code Signing (KMCS) policy included in Windows Vista x64 editions.   In Windows Vista x64 editions, the default KMCS policy is to only allow code to load into the kernel if it has been digitally signed with a valid code signing certificate.


 


The Atsiv driver also provides a means to load unsigned kernel mode code in a manner that is not visible through operating system provided API interfaces (such as the EnumDeviceDrivers() API), and this may allow the code to hide from view of commonly deployed tools.   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.


 


KMCS is a not a security boundary, rather, it is only one aspect of a defense–in-depth approach to security.  KMCS does not provide a means to determine the “intent” of the signed code (i.e., good or bad); indeed, signed code may contain bugs, be of poor quality, or may be malicious in nature.


 


A primary benefit of KMCS is that it provides a means to identify the author of a piece of code, which helps enable follow-up with the author to address crashes that are observed through mechanisms such as Microsoft Online Crash Analysis.  Identifying the source and ownership of code that is loaded by the kernel is a fundamental component of the operating system and overall ecosystem trust model.    Furthermore, this also provides better transparency to the end user in terms of origin of code that is installed and running on a system.


 


In the case of the Atsiv kernel driver, the defense-in-depth measures provided by KMCS worked as expected:


1.       Complete anonymity was prevented.   The author of the driver is identified through the code signing certificate, and action has been taken, which is discussed below.


2.       Integrity checking of the Atsiv kernel mode code was provided.  The AtSiv driver is integrity checked by the operating system prior to it loading and executing.


 


Microsoft is committed to protecting its customers from potential as well as actual security threads; accordingly, we are responding to this issue as follows:


 


1.       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.


2.       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. 


3.       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.


 


In short, we 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.


 


Scott Field


Comments (123)

  1. I’m confused about certificate revocation. #3 above indicates that the Microsoft revocation list (is this a list for cross-certificates?) is only checked at driver load time, thus a reboot is required. What about the VeriSign revocation? Is this also checked only at boot time, or more frequently?

    Also, why would you be investigating adding it to your own revocation list? If it’s good enough for VeriSign’s revocation list why would it not qualify for yours?

  2. sf says:

    Currently, the kernel mode revocation list is loaded into memory, from disk, once per system boot.  The kernel revocation list is checked when the operating system kernel code loads a kernel driver/module.

    There are several reasons for keeping the logic for this simple in kernel space – for example, constraints in the kernel runtime environment, as well as limiting the attack surface associated with the kernel loader.   There are also other practical factors to consider, such as kernel drivers that have already been loaded cannot always be unloaded or removed safely on a running system (they may be malicious in this regard, or they may not implement the driver unload routine, for instance).  In these fairly common situations, a reboot is already required to remove the driver from memory.    This property is also true of certain patching/updating circumstances – a reboot is required for the patch to be effective.   You can also see this in some cases where security products require system reboots when removing specific threats from an infected system.

    The VeriSign revocation list may impact a variety of operations.  For example, verification checks that request online CRL validation will fail, which is more common for user mode operations.  This can also extend to functions such as online time stamping combined with signing of new code.  The frequency of these checks is application specific, and also depends on factors such as the requested CRL verification policy (online network, vs. offline without fresh cached CRLs, etc).

    Microsoft is assessing adding this to the Microsoft kernel mode revocation list.  If added, this will be the first entry in the kernel mode revocation list, and does require careful testing and validation.   The Windows Defender signature update does provide a means to detect/block/remove current Atsiv components.

  3. Windows Vista wymaga, by sterowniki były podpisane cyfrowo. Oczywiście na ten temat była już długa dyskusja, między innymi pojawiały się zarzuty iż wymaganie to "ma ograniczyć konkurencyjność"… Ostatnio pojawił się sterownik/program Atsiv

  4. n4cer says:

    Code Integrity also performs a cert check upon installation of the driver, so CI would see VeriSign’s revocation at that point. I’ve seen this in action when I installed an updated NIC driver that the IHV mistakenly published with a test certificate. When the driver didn’t load, I checked the event log and saw the CI failure, so I then checked the cert, saw it was a test cert, and notified the IHV of their error.

    However, if the Atsiv driver is a boot start driver, the loader wouldn’t have access to the cert store at boot time so it checks the driver’s embedded signature against the Microsoft Code Verification Root and global revocation list to determine whether the driver should be loaded. Microsoft would need to push an update to their revocation list (i.e. a new signed binary) so the loader would know not to load the revoked driver. MS’ investigation is probably to evaluate which would be the best ship vehicle for the update.

  5. How hard would it be to write a program that cycles through running programs and drivers (it would, itself, have to be a signed driver I guess) and performs revocation checks on them?

  6. John says:

    On what basis was the Verisign certificate revoked?  I’m uncomfortable with the idea of CA’s becoming the software police.  Atsiv may be an easy case, but what precedent does this set when less cut-and-dried cases arise?  Working around limitations in an operating system is not necessarily a bad thing.

    P.S.  I’m not really concerned about how Windows Defender or other AV products handle this, since people make a free choice to run those programs.

  7. Phil says:

    Wow, no sooner than I manage to get my parallel LCD working in Vista x64, than MS break it again.

    Whilst I have some sympathy for MS’s position here, I still believe that I should be able to control what runs on my hardware. On top of the fact that I never got BSOD’s on XP (x64) when it was using unsigned drivers.

    I’m still suspect this is all about DRM. But as I don’t want to play any DRM’d media, I don’t see a lot of point in that stopping me run unsigned drivers either.

    <sarcasm>I’m so grateful to MS for not allowing me to use my own hardware at my own risk.</>

  8. VeriSign has a long history of revoking signatures for malware. Here’s their rat-out form: http://www.verisign.com/support/code-signing-support/code-signing-misuse/index.html

  9. rk says:

    Re:DRM.

    You can control what driver signing policy on your system enforces, since you are presumably the administrator on your system.

    See http://www.microsoft.com/whdc/winlogo/drvsign/kmcs_walkthrough.mspx

  10. What rk says underscores the fact that KMCS is no protection if someone 0wns your system as administrator.  The real protection in the Atsiv scenario is the UAC warning. Of course you can be an idiot and turn that off too.

  11. John says:

    I wouldn’t automatically classify loading unsigned kernel code on X64 Windows as "malware".  It could enable malware, but it could also enable open source drivers with the knowledge and consent of the computer owner.  I have trouble with "might be used for evil" being the standard for certificate revocation.

  12. rk says:

    WRT: "but it could also enable open source drivers with the knowledge and consent of the computer owner"

    As stated in the previous post, and emphasized by Larry,  the admin can change the driver signing policy, so you (as admin) can already load open source drivers that you (as admin) approve of. The Atsiv driver did not enable any such new functionality.

    In terms of revocation policy, would you object if I installed a driver on your system with a known bug that exposed k-mode to unprivileged u-mode code ;-).

  13. Phil says:

    @ RK

    You may be able to disable driver signing using the boot menu, but who really wants to remember do this EVERY boot? Hardly ideal. (I’m going to study that document later in case I missed something)

    There is a way to do it using BCDEdit but apparently this will be broken (fixed) with the next updates form MS.

    And I’m not talking about building test signed drivers, that would mean (as far as I can tell) building a OSS driver and giving it a specific test cert, that will only run on the once machine?

    As for only the foolish disabling UAC… I have UAC enabled but I’ve removed the prompts when using an admin account. Thanks very much but I’m quite capable of determining what I run on my system, and reinstalling it when *I* mess something up (which is very rare). Again, I understand UAC and think its great… for my Parents and mr Average PC user… At least with UAC, you *CAN* turn it off if you so desire.

  14. rk says:

    WRT Phil.

    a) Was it announced somewhere that bcdedit options were going to change? Is there a URL that we can look at to confirm the correctness of your statement? Eagerly awaiting ….

    b) Test signing is on a per-machine basis, but AFAIK, you are the admin only a per-machine basis. I certainly don’t want *your* test signed drivers on *my* machine.

  15. Ben says:

    It would appear that Microsoft’s aim is to ensure that peoples personal computers does what Microsoft wants them to do rather than necessarily what the owner wants them to do.

    Recently I bought a Bluetooth headset so I could make voip calls. I expected that I would be able to use the Bluetooth adapter in my computer and connect to it. Unfortunately the Bluetooth drivers shipped with Vista would only recognise the device but could not support hands free audio. I was able to get some 3rd party drivers, unfortunately they were not signed.

    Thanks to Atsiv I could freely download a tool which enabled me to load my unsigned Bluetooth drivers without affecting the features of the operating system, namely being restricted from playing certain DRM media. While the whole issue of DRM is a controversial and complicated matter, I don’t feel that in this case by simply wanting to use the Bluetooth device I bought with the computer and operating system I also bought should be interpreted as a means to circumvent copyright.

    Worse still, if I was unlucky enough to be running Vista x64 edition, I would have to press F8 each time the computer boots up and manually select the option to load unsigned drivers.

    I appreciated the tool Atsiv that enabled me a choice I felt I should have had already with the operating system I purchased. I feel less appreciative of the efforts of Microsoft to remove this choice from me.

    I am also concerned about the implications of Microsoft’s ability to have the signing certificate revoked. My understanding of signing certificate is protection to the end user that the file (in this case the Astsiv driver) has not been modified since it was signed by the author. The author is identified through the signing process giving me the choice as to whether I want to trust this. If I trust it then I can be confident that it has not been modified by someone else to do something else. In this case the program does exactly what it claimed. I installed it myself, I read the document describing what it would do, and am happy to have this running on my system. In addition the UAC mechanism works as intended to protect my computer from a malicious program attempting to install Atsiv without my knowledge.

    However it appears that Microsoft has decided to take the signing authority further and is using it to ensure that programs do not contravene Microsoft’s self created policies.

    This is an interesting case of Microsoft not only being self appointed police, but self appointed policy makers.

    It should be noted that there is in fact nothing illegal about the Atsiv utility, nor is it illegal for me to use a Bluetooth headset with Vista. There is no law that states unsigned drivers must not be loaded into the kernel of an operating system, this is simply something Microsoft themselves have decided.

    While the circumvention of DRM may be illegal in certain jurisdictions, the idea that Atsiv may be used in the process of circumventing it is a very weak argument. Microsoft themselves release a product called Visual Studio. This contains various compilers, assemblers, and an entire SDK for programming anything on a windows platform. Visual Studio can be used to write a program designed for bypassing DRM or in fact any thing else the author intended, whether for good of for malicious reasons. Malware can, and most probably is, written using Visual Studio.

    Now I do not claim that Visual Studio is in anyway a malicious program, it simply does what it advertises it does. It enables people to write programs of their own choosing. Likewise Atsiv does nothing malicious itself, it simply allows people to load other drivers of their choosing. I would argue that if Atsiv is to have its signing certificate revoked, then under same reasoning Visual Studio should also have its certificates revoked.

    One final comment I would like to make is the fact Microsoft’s response to this does nothing to protect users from malware. As Atsiv demonstrates, it is very easy for anyone with a few hundred dollars to get a signing authority. While this might be a deterrent to some authors, the Malware industry is big business these days and will not be a hindrance to them whatsoever. I fully expect the next time a major music distributor decides to embed a root kit on their CDs it will be signed, and therefore allowed right in by Microsoft.

    Ben.

  16. n4cer says:

    The security implications of allowing code such as Atsiv to go unchecked should be clear. It has nothing to do with DRM. Atsiv threatens system integrity by circumventing defined interfaces, allowing arbitrary loading and execution of kernel mode code, and hiding that code from the user and the operating system. This is rootkit behavior plain and simple, and it should be obvious that it’d be used as a toolkit for distributing malicious payloads.

  17. Matt says:

    n4cer, you are over stating the threat of Atsiv towards system security.  In order to load Atsiv, one must have Administrator privileges.  If one has that, regardless of what tool is being used, system integrity is at risk.

    Security tools that implement code patching to give them control over system flow aren’t classified as exhibiting "rootkit like behavior".  Why do you classify Atsiv as such when it simply implements the very much documented Windows Portable Executable format to provide support to an area of computing that Microsoft has decided to snub?

  18. Ben says:

    I don’t think the case is as clear as you state n4cer. For example in the 32 bit version of Vista (which is by far the most common in use currently) this is entirely about DRM. 32 bit Vista will allow unsigned drivers to be loaded, it will however disable playback of certain DRM media. I would suggest that the average Malware author will not care if the installation of their driver causes a denial of service to the user, they will be happy enough that they got execution. So in the 32 bit case there is no case to be made that Atsiv can threaten stability.

    The claim that it will be used as a method of installing malicious payloads is probably correct, but that is not the fault of Atsiv that it may be used in that manner. I have seen Malware use cmd.exe in order to achieve their nefarious activities, but I don’t blame cmd.exe for this, nor would I wish it to be removed off my system.

    Additionally Atsiv does not attempt to “hide code from users and the operating system”. The fact that Atsiv itself is loaded will be visible to the system. The additional drivers that it installs won’t be listed in the driver list simply because it wasn’t installed that way, not due to sneaky behaviour. The memory that the drivers are running from is not cloaked in any manner, they will be visible to the system as memory allocations. Atsiv certainly does not try to hide its activities from the user. Atsiv was designed as a tool for the user, as a consequence it provides a way of listing all the drivers that it has loaded.

    Ben.

  19. Peter says:

    This sets a VERY bad precedent.  As you said "the defense-in-depth measures provided by KMCS worked as expected."  So the KMCS system worked as designed but you just didn’t like what the driver did so you had it removed and revoked.

    As others have said, this case _might_ be an easy one, but I don’t like the idea that MS can be the sole arbiter of what I can and can’t run on my machine.  What happens when a vendor releases a driver for a piece of software that competes with a MS product?

    If the author of this particular piece of software followed all the procedures and didn’t falsify or misrepresent any of his credentials and paid for a legitimately obtained signing certificate for a piece of software that does exactly what he said it is supposed to do, who are you to say "No, you can’t do that with your computer?"

    I really don’t like where MS is going with this.

  20. It’s not fair to say Microsoft is the sole arbiter here. I’m sure VeriSign made up their own minds about revoking the cert, and I know of many other examples of them doing so.

  21. Dave says:

    What is required is for Microsoft to allow end users to explicitly sign their own drivers/executables etc, and be able to configure their own machines to trust their own signature.

    This deals with malware effectively, complies with the KCMS policy, and deals with open source in an appropriate manner.

    End users should ultimately be allowed to decide what software they trust.

    I don’t want to have to disable KCMS just to use my computer. Overall I *LIKE* what KCMS does and am enthusiastic about code signing, but Microsoft/Verisign shouldn’t be the final authority that decides what signatures my computer trusts.

    I should be the final authority for any machines I own/manage. Thus their should be tools to allow me to easily sign and authorize whatever I want.

    Atsiv wasn’t the right way to solve this; but it was a welcome workaround to overcome fundamental deficiency of Vista x64’s driver signing system.

    As far as "DRM" goes, and the potential that someone might violate a copyright by signing a driver, and loading it onto their own system, so be it. Let the media industry prosecute criminals who actually break the law rather than restricting all individuals freedom to use their computer as they see fit, simply because they MIGHT infringe a copyright.

  22. Michael says:

    This is a very interesting thing Microsoft have done. The Microsoft logic seems to revolve around Atsiv being "Undesirable" or misrepresenting itself in some fashion. There have never been claims of deception in obtaining the signing certificate, or that the Atsiv tool does anything other than what it claims.

    To describe this tool as "undesirable" stretches that word beyond reason. Atsiv has no self-propogating functionality. It doesn’t do any privilege escalation or modify any system functions or memory or anything like that. It uses (I assume) documented windows APIs to provide functionality that some people clearly desire. You need to be an administrator to run it. You will see the UAC dialog (if enabled.) If people choose to download and run it on their own computers, then it is providing "desirable" functionality, by definition.

    RK says "In terms of revocation policy, would you object if I installed a driver on your system with a known bug that exposed k-mode to unprivileged u-mode code ;-)."

    Would you object if I decided to install a driver on MY OWN SYSTEM with full knowledge of the consequences? To rephrase the question, if there is only one option for a driver, and I do the research and choose to install it, why is it your decision to stop me? Yes – this tool allows user-mode to access kernel-mode functionality. That’s the point. That’s the u/kernel model. And in this case it’s not a vulnerability or a flaw, it’s an option. Choose to take it up or not, but allow me the same choice.

    I was also interested to read in the first paragraph that the DEFAULT KMCS policy was only to allow signed drivers. The word policy implies that it’s a user controllable thing. Well, as pointed out, you can disable this "option" with f8. So really all atsiv provides is a more convenient boot process. Great. Tell me how that is "undesirable."

    If requiring that drivers be signed under vista 64 was an option, then atsiv would be unnecessary. As it is, it makes one aspect of vista more convenient.

    Dave : I love your logic. How about waiting for people to break the law before punishing them for it?

  23. Joe says:

    Congratulations Microsoft you revoked a certificate for a useful tool that did exactly what it advertised.

    What are you doing to stop real malware that don’t advertise? Or as Joanna Rutkowska pointed out insert intentional vulnerabilities?

  24. Ben says:

    I suspect this is the start of a cat and mouse game that Microsoft may not wish to pursue. While it appeared easy for Microsoft to revoke this signature, I suspect it involved a lot of work by a group of people to sort through all the issues and processes. It apparently only takes a couple of hours and a few hundred dollars to get a signing certificate as Joanna Rutkowska demonstrated in a presentation recently. The current Atsiv certificate has now been revoked, however whether the authors of Atsiv choose to repeatedly release Atsiv with new certificates is irrelevant to the game. Anyone is able to acquire a certificate, and anyone can take the existing Atsiv tool and resign the driver with their new certificate. Microsoft provides the tools necessary for signing binaries. A quick look at the Atsiv executable reveals that the .exe itself is signed, and contains two resources which are the 32 bit and 64 bit drivers. Using a tool such as Resource Tuner makes it easy to extract the drivers, sign them with a new certificate, and then place them back into the executable. Given the relative ease of this, and the probability that there are a large number of people wishing to have a tool like Atsiv around, I can imagine many versions of Atsiv popping up around the internet all with different signatures. This could become quite a bother for Microsoft to keep up with. Also we can expect that only some of the newly signed versions will be advertised. The ones intended specifically for nefarious reasons are unlikely to be widely broadcast.

    Ben.

  25. Marcus says:

    Ben, I would suspect the Microsoft Defender signatures would block Atsiv clones regardless of who signs them.  At least they should be blocked if Defender is any good at what its supposed to do.

  26. Michael says:

    I think having a windows defender signature for atsiv is completely reasonable. If people don’t want to be running it, then windows can let them know about it. But users should also be free to choose to.

    As I understand it driver signing is primarily to determine who authored a piece of code (attribution). And in this case the author is well documented, Linchpin labs. So why exactly was this certificate revoked?

    As Joanna Rutkowska pointed out, there are signed drivers with vulnerabilities (such as Nvidia.) Malware authors could package these drivers, install and then exploit them (even on boxes without the relevant hardware). Kernel mode code is now running on a "requires signed code" machine. So if the litmus test for revoking a certificate is "Could possibly be used for evil" then how about pulling Nvidia and ATI’s certificates as well?

    Or would that be too fair of a fight?

  27. Green says:

    That’s right. Defender will complete block Atsiv drivers from running on all systems. I think the case is closed.

  28. rk says:

    Some comments:

    a) Dave: "What is required is for Microsoft to allow end users to explicitly sign their own drivers/executables etc, and be able to configure their own machines to trust their own signature". You *can* do that already. Just RTFM on publicly available documentation. (http://www.microsoft.com/whdc/winlogo/drvsign/kmcs_walkthrough.mspx)

    b) Michael: "Would you object if I decided to install a driver on MY OWN SYSTEM with full knowledge of the consequences? To rephrase the question, if there is only one option for a driver, and I do the research and choose to install it, why is it your decision to stop me? " No one is stopping you. See the answer a) above, and some of the prior posts allude to this too. Again, RTFM.

    Documentation is a wonderful thing, but only if you read it.

    Last post.

  29. Marcus says:

    rk, are suggesting that the common developer just get his/her own signing authority?  Have you ever gone through the process of signing a driver yourself, or getting signing authority?  Just in case you haven’t, you need several methods/documentation that support the existence of a business.

    Or perhaps you are referring to test signing?  Have you verified that test signed drivers will NOT get in the way of me watching my favorite DRM protected media?  Seems like an awful silly thing if Microsoft has ths loophole build into the development process…

    Otherwise I have missed what you are referring to when I RTFM.  Thank you for your unconstructive comment.

  30. Timmeh says:

    Dear Microsoft,

    May we have our computers back please?

    Signed

    The Users

    No really. Can you go back and write a new OS, this time putting the customers needs first instead of forcing some destined to fail DRM down our throats at the whim of the media mafia?

    Also, I appreciate being given as much information as possible when making a decision but I would like to make it for myself, not have Vista tell Me what IT wants to do. I think I speak for most when I say give us an option to permanently disable this crummy feature.

  31. Steve R says:

    The fact that Vista 32 refuses to play DRM protected media while running traditionally loaded unsigned drivers is a pretty good indication of Microsoft’s real push to enforce driver signing.

    BTW, I downloaded the latest Windows updates and Atsiv still works.

  32. Mike says:

    Isn’t searching the revokation list a O(log n) operation per driver at best? Assuming one revocation per month, what happens to the revocation list as time goes on?  The proper attack approach discussed by Atsiv is to devalue the mechanism by repeatedly attacking the revokation process? Its bad when the number of revocation exceed the number of certs. Its really, really when the number of revocations exceed the number of certs by some factor of X.

  33. Ben says:

    Rk, you suggest that Windows already allows a user to install an unsigned driver by being able to sign the driver themselves with the mechanism that Microsoft provide. While this is technically true, I would like to make a few points.

    1) If each user is to get their own signing certificate to sign otherwise unsigned drivers, then this is going to cost each user several hundred dollars which they may be unwilling to pay for having already bought the OS.

    2) If instead the user configures Vista to allow self signed drivers to be installed and uses self signed certificates then they will be subject to certain DRM denial.

    3) The process of signing files is not a trivial task that would be suitable for the average user. Nor are the tools required shipped with Vista, but rather with something like Visual Studio which is not a standard application on most computers.

    Finally, I would like to add that while this would appear to be a legitimate method of loading an otherwise unsigned driver because it is using Microsoft documented methods, I wonder how this differs greatly from what Atsiv set out to do. Atsiv used Microsoft documented methods in order to write a PE file loader in the Kernel.

    Ben.

  34. sf says:

    A few comments:

    1.   Regarding open source kernel drivers.  There are already examples out there of open source drivers that are signed with a valid signing key.  truecrypt is one example (www.truecrypt.org).

    2.   Regarding "usability" of the tool, and applicability to drivers which may not have been signed properly.   The average end-user is not going to have any idea which .SYS file needs to be loaded if a device is failing.  Nor is the average end-user going to have any idea how to use the command line to load .SYS files.  Do you want to be teaching the average user to do this, plus the requisite elevation, on every system boot?  There are also documented limitations in the tool (readme.txt), like the need to load dependencies before loading the .SYS file.  Video drivers are common examples where many dependencies on kernel .DLL files may need to be loaded before the .SYS file is loaded — an even more problematic issue to hoist onto the end-user.

    3. Related to #2, there is a point where’s it’s more reliable and practical to ask the vendor for an updated/properly signed driver, OR [test] sign it yourself.    If a vendor provides an updated driver, this is more desirable outcome than running kernel code of potentially unknown origin.  Note that when the system is in test signing mode, the user is also alerted to this configuration, via decorating the user desktop with appropriate text.

    4. I’d be very interested to learn specifics of the unsigned x64 drivers that people are encountering.  Can you submit comments with device, model, and manufacturer information?  One or two cases were mentioned in the comments here, we’d like to see if any outreach is needed here, beyond what was already carefully planned/executed as part of the Kernel mode code signing rollout.

    5. Larry asked about how to programmatically check CRLs on drivers that have been loaded by legitimate means (but not those loaded by AtSiv, which won’t be visible to the system provided driver enumeration functions).   The relevant API to use for this are EnumDeviceDrivers(), GetDeviceDriverFileName(), and WinVerifyTrust().   We’ll investigate augmenting the system explorers in Defender to do this for drivers — it already displays some digital signature information for running programs and certain extension points.

  35. Steve R says:

    Nicely put sf or Scott Field?

    But if 1) I don’t want to belong to a community to have to sign something I wrote 2) I’m choose to undertake the learning curve to learn what a .sys is 3) the vendor doesn’t support the hardware anymore or I am the vendor (because it’s my own code) 4) I want to watch movies and use my hardware 5) I don’t care what the CRLs of the other drivers are.

    Would it be that unreasonable for me to make my own mind up and use Atsiv? I’m sure you make great decisions but I don’t try to tell you what to wear – why do you think it would be a good idea to tell me what I can or can not run on my own computer?

  36. If there’s actually user demand for self-signing drivers with personal code signing certs someone (VeriSign? InstallShield?) will write a tool to make it easy to do.

    Of course this isn’t going to happen because average users won’t want to do this. They’ll want to run drivers they get from vendors. By the time average users are using Vista-64 it will be a market requirement for everyone to sign their drivers.

  37. dimstar says:

    Well well, an interesting case.

    But since when is Microsoft about a choice for the user? The user never was asked for his opinion…

    MS declares that driver brings it’s system (be it the OS or the DRM system) at risk, so THEY decide to get rid of that driver. There is (from MS PoV) no reason to ‘bother’ the user with such ‘technical’ decisions.

  38. Inak says:

    While I agree that tools like Atsiv could be used for malicious things, Linchpin was completely aboveboard with it.  

    There are many other things that can be subverted – for example, for a hacking demo a few years ago, a friend wrote a small program that launched from a web page, silently uninstalled Norton Anti-Virus and installed small service EXE that put a fake NAV icon in the system tray.  All of this was done with information freely available from Symantec’s and Microsoft’s websites and a little knowledge of Visual C++.  NAV didn’t flag a warning that anything happened, didn’t write anything to the event logs although the Microsoft Installer did write an "uninstall successful" message to the Application log.

    My point is, where do we draw the line between something that’s useful but has the potential to be abused and real malware?

    And what about Verisign?  Many, many people and companies rely on them to validate applications, websites, etc.  If they’re willing to revoke the cert for Atsiv this quickly and on just Microsoft’s say-so, this makes me question the validity of anything they’ve certified.

    Or maybe this just proves that…

    1 – Microsoft is far better qualified to say what I can run on my computer than I am even though I’ve been working with computers for more than 25 years – almost half of it in some aspect of OS and network security.

    2 – Microsoft is the ultimate authority on Windows security (even though they generally issue more Windows security patches in a single month than Novell released for Netware 4.11 during the entire life of the product).

  39. Jeff Flowers says:

    Personally, I agree with Microsoft’s decision in this matter. In fact, this is one of the reasons I use Vista x64.

    As for the revocation, I would say that Microsoft should have ultimate authority to revoke driver signings. From what I can see, Verisign simply provides the technology to make driver signing possible so that MS doesn’t have to.

  40. John says:

    Jeff:  That you like Microsoft’s choices is really irrelevant to this discussion.  Nobody is saying that you shouldn’t be able to require signed drivers.  The question is whether Microsoft should impose your choice on other people who don’t agree with it.

  41. rk says:

    WRT a statement made by Ben:

    Ben,

    DRM policy is set by the DRM server (content providers), and not by Microsoft. A conversation on whether DRM is good or not, whether it benefits society, makes cat fur more fluffy or not, or whether it can/should be broken, is not a conversation that I’m qualified to have.

    Instead, think of Kernel Mode Code Signing as default admin policy for the kernel, that the admin can change if he wants to. In analogy with my car, I’m glad that my car has airbags that deploy by default. I could disable them, if I wanted, but I generally choose not to. I suspect that the large majority of users also feel similarly about default policy on a system.

    I don’t think that kernel mode code signing changes the admin = god model in any fundamental way.

  42. Steve R says:

    Unlike Joanna, Linchpin did not distribute source code, only a *signed* binary.  Thus, it did exactly what it said, in a manner that guaranteed it had not been tampered and in a fashion that would be USELESS for malware.

  43. Alex M. says:

    rk,  I’m just a newbie, but you’ve twice referenced http://www.microsoft.com/whdc/winlogo/drvsign/kmcs_walkthrough.mspx

    and, in your post to Phil of 8/3, you suggest that BCDEdit can be used to disable driver certificate checking.  

    Yet, the concluding paragraph of the walkthrough states,

    "Note: Formerly, Windows Vista Beta2 provided a BCDedit option—“nointegritychecks”—that allowed unsigned drivers to load for testing purposes. This option was available only for the Windows Vista Beta 2 release. The “nointegritychecks” option is no longer supported by the Windows Vista operating system loader (Winload) or the kernel. Setting the option on Windows Vista RC1 and RTM completes successfully and BCDedit displays NoIntegrityChecks as true (Yes); however, it has no effect on the behavior of the operating system’s loader or kernel. For more information, see the Boot Configuration Data Editor FAQ on the MSDN® Web site. For more information on boot configuration data (BCD) and BCDEdit, see the white paper titled “Boot Configuration Data in Windows Vista.”

    Doesn’t this leave only the cumbersome options of loading a debugger or signing one’s own driver as a means of bypassing the certificate check, should an informed admin wish to do so?

    The "F8" option only lasts for a single  boot session.

  44. Arms says:

    This is all cute… but like the guy up there said… Microsoft is always at fault.  If they do something wrong (which they do most of the time) we complain… if they offer a patch, we get irritated about it.

    It’s about time Microsoft take actions for the security of THEIR software.  If you don’t like Windows (whichever version you are using), get something else. (any type of linux will do) or get a Mac (which honestly, I detest)  Macs are evil things.

    Anyway, rambling aside… I sympathized and encourage Microsoft to do anything to secure THEIR software.

    We, the users (specially admins) are responsible for whatever enters our "computer" systems; it’s not Microsoft fault.  

    Let me leave it at that.

    Peace,

    Arms

  45. marketguy says:

    >Anyway, rambling aside… I sympathized and encourage >Microsoft to do anything to secure THEIR software.

    But once I bought that software I consider it MINE, and from then on I do not want any control from the side of Microsoft!

    But anyway you are still right so far: People should buy other systems than Windows if they are not happy with what Microsoft does. And there should be many more people really DOING that instead of just complaining!

    This would certainly improve Windows a lot, because it would mean that the free market would start to force Microsoft to really listen to their end users.

  46. Auch wenn die funkelnde neue Benutzeroberfläche von Windows Vista durchaus ihren Reiz haben mag, immerhin war das Standardskin von Windows XP ja ein gehöriger Griff ins Klo und die Benutzung ohne dauerhaften Augenkrebs nur im Classic-Look beziehungsweis

  47. Ahmet Caliskan says:

    And don’t forget : Microsoft has never abused its monopoly to drive competitors out of market. We are all confident that they will not abuse this kind of power, too.  

  48. marketguy says:

    I forgot one important point: I DON’T blame Microsoft for the laziness of those Windows users who only complain but do not take any actions, because it’s THEIR fault that Microsoft is now so fat and unattentive towards end user needs and wishes, but listen to others like the DRM lobbyists!

  49. Alan says:

    Why haven’t I gone to VISTA?  Unsupported drivers, some for old hardware where the vendor will not spend the time or money to write a new driver.  As an IT professional and security manager, I understand that drivers are the greatest cause of OS instablity.  But this should be a risk that users (and enterprises) should be able to take.

    Causing a third party (Verisign – famous for its own security) to revoke a companys certificate sounds to me (did I mention my law degree?) to be tortious business interference or an antitrust violation.  The currentUS government is not about to take on Microsoft for any reason.  It is too bad that a little company does not have the capital to wage an antitrust battle against Microsoft.

  50. sf says:

    Additional comments:

    1. With more research on the Atsiv driver, it turns out this component does leave the system open to a new attack from a non-administrative context.  That is, after an administrative user has run the tool just once, ANY user can then load arbitrary code into the kernel, including standard non-administrative users.   You can reproduce this by running atsiv -l (from a command prompt running as Administrator — just once), and then run any other Atsiv command from a standard/limited user context. This behavior is not covered by the Atsiv documentation, and is likely an oversite by the authors.  But this leaves the system open to attack in a way that isn’t apparent to the end-user.

    2. Larry Seltzer asked about checking the status of loaded drivers.  Earlier, I responded that EnumDeviceDrivers(), GetDeviceDriverFileName(), WinVerifyTrust() APIs could be used.  Unfortunately, with more research, it turns out that Atsiv deletes it’s driver image from disk, after the image is loaded into kernel memory.  So, the attempt to verify the signature on the disk image will clearly fail.   This load/delete type behavior is also not typical of production software — some may go as far to say this is malware like behavior.

    3. The poster "rk" is likely referring to enabling test signing mode.  "Hobbyists" which are producing drivers not meant for broad distribution may use this option, in addition to the kernel debugger and F8 per-boot option.  The KMCS documentation referenced earlier covers test signing mode.

  51. concerned says:

    sf, most SysInternals tools use this "load/delete type behavior". Dont forget (actually you would know) Microsoft owns SysInternals. SO can we label Microsofts "not typical of production software" as malware as well?

  52. concerned says:

    sf, most SysInternals tools use this "load/delete type behavior". Dont forget (actually you would know) Microsoft owns SysInternals. SO can we label Microsofts "not typical of production software" as malware as well?

  53. Steve R says:

    If Atisv had been a utility to allow running LINUX drivers on Windows, would that have also been classified as malware?

    If the argument is that the problem is Atisv allows loading of unsigned drivers, that’s already allowed, and thus under the same criteria Windows itself is malware.  If the argument is that Atisv does not add the drivers to the loaded module list, one can argue that this would disallow drivers that load firmware or download patches or any other dynamic sort of content (including the theoretical Linux compatibility wrapper.)  Indeed, I cannot fathom any reason why Atsiv would be classified as malware under any reasonable interpretation.

  54. Ben says:

    Scott, your comment about Atsiv leaving a system vulnerable is valid. It would appear an oversite by the authors that once the Atsiv driver is loaded, unlimited drivers can be added without the requirement of administrative rights. This would be fairly easy to rectify I expect, and I imagine if Linchpin Labs releases a new version this will be one of the changes made. However the fact that there is this concern is not a reason to have the product banned. I assume Microsoft is not planning to revoke licenses any time a driver is written with an inadvertent vulnerability.

    Various people have made comments about it being easy for Linchpin Labs to get a new certificate and release the tool again. As the tool was written with good intentions in mind I would imagine that Linchpin Labs would be more than happy to address the various concerns such as not loading the MZ stub, placing the loaded drivers in the system drivers list (thus ensuring that DRM applications will be able to see unsigned drivers on the system), and of course the security concern you just raised. Whether they do release a new version is up to them, though I expect that they would be less keen to purchase a new certificate just to have it revoked a second time. I would be interested to know what Microsoft’s view of a new version of Atsiv would be. Are they going to ban anything that resembles it, or would they consider the above changes sufficient?

    Ben.

  55. michael says:

    I applaud to Microsoft’s actions here, and find it funny how everyone gets upset at them.

    Vista Pwned Inc. developed a driver to supposedly show how easy it is to undermine the kernel code signing policy, according to their page, sarcastically asking "what KCSP actually represents" and making Microsoft look bad because of the security issue that driver would now represent.

    Microsoft then proceeds to revoke the driver, and suddenly Vista Pwned Inc. changes directions completely – now suddenly they’re worried and see this as a "concerning incident" just because they can no longer pwn Vista.

    So basically, if Vista loads the driver, they see it as bad because of the security implications involved, and if it doesn’t load the driver, they see it as bad because it’s a worrying incident that a driver with these security implications is not loaded? Make up your mind, seriously. It’s too bad Microsoft has to spend time dealing with all this crap whilst attempting at all times to maintain a professional attitude – maybe they should name the Defender Signature updata "Vista Pwned Inc. got pwned", backwards?

  56. Zmidponk says:

    I’ll summarise what seems to have happened, the way I see it:

    Atsiv did not try to hide what it did.  It did not mislead anyone in what it did.  It stated what it was trying to do clearly and concisely – allow the loading of unsigned drivers in Vista.  It obtained a legitimate certificate on that basis.  It managed to do exactly what it clearly and concisely stated it did.  Microsoft then revoked the certificate because Atsiv did exactly what it was supposed to do, stated it was trying to do, and was designed for the purpose of doing.

    Does anyone else just find that extremely stupid?

  57. Richard says:

    I think you are being a bit harsh Michael…

    Driver signing is a good direction for improving overall system stability as it helps Microsoft identify poorly written drivers.  However, driver signing as its stands today is not an effective means of security for several reasons.  Firstly, any person or company who has gone through the process can attest to how trivial it actually is to acquire a signing certificate.  Secondly, signed code does not account for the quality / intent / methods of a product.  In fact, signing only guarantees that the code that is signed has not been tampered with and is attributable to a specific entity (although this in itself is a product of jurisdictional standards).  The reality is, any entity that intends malicious activity can easily acquire signing authority, and any supposed security/protection/control benefits of signed code become nullified.  

    According to the authors, Atsiv was born from a research project to highlight this.  You could have a machine loaded with signed malware drivers, and nothing in Vista will detect or prevent this.  I think that was the point the authors were trying to make as part of their research.  This is also why Microsoft’s revoking of the cert has ZERO benefit, as it builds off of an already shakey security policy which in the end doesn’t really make Vista’s kernel any more secure.

  58. Smidgy says:

    Michael, the reason this is a ‘concerning incident’ is that Microsoft revoked Atsiv’s certificate apparantly because it could indirectly be used for malicious purposes.  It is concerning because the same standard can be applied to one HELL of a lot of perfectly legitimate programs, with the deciding factor as to whether it will be or not seemingly being what mood Microsoft are in.

  59. Joe says:

    Wake up and smell the coffee, people – are you just now realizing that Microsoft is bound and determined to control all computers and allow nothing but Microsoft code to run on them – or have you already forgotten the DR-DOS "incompatibility" issue?

    Don’t buy Vista, download Linux instead – hit MS in their wallet instead of moaning about it.  I will not be using Verisign for anything, given that they punked to MS so easily.

  60. Peter says:

    Today I read of Alex Ionescu’s PurplePill that exploits an ATI signed driver. PurplePill is an executable that has an embedded exploitable ATI driver. The executable extracts the vulnerable ATI driver, loads the driver then exploits it to get ring 0 shell code execution (which can then be used to load any unsigned driver).

    The Atsiv utility did exactly what it said it did and was easily identifiable. Because it made no effort to hide itself it was less likely to be used by malware (which unfortunately made it easy for Microsoft to block and revoke it). PurplePill on the other hand is exactly what malware will use. Good luck revoking the certificate for every ATI driver out there Microsoft.

  61. zzz says:

    All the ATI drivers crash here (???????) very reliably. Could you revoke them 🙂

    71a73719 761d            jbe     atiumdag!OpenAdapter+0xf1348 (71a73738)

    71a7371b eb03            jmp     atiumdag!OpenAdapter+0xf1330 (71a73720)

    71a7371d 8d4900          lea     ecx,[ecx]

    71a73720 8b17            mov     edx,dword ptr [edi]  ds:0023:1ccdb000=????????

    71a73722 83faff          cmp     edx,0FFFFFFFFh

    71a73725 742f            je      atiumdag!OpenAdapter+0xf1366 (71a73756)

    71a73727 015624          add     dword ptr [esi+24h],edx

    71a7372a 83c001          add     eax,1

    71a7372d 83c710          add     edi,10h

    71a73730 3b8340040000    cmp     eax,dword ptr [ebx+440h]

    71a73736 72e8            jb      atiumdag!OpenAdapter+0xf1330 (71a73720)

  62. Ben says:

    Once upon a time all code was equal. A major corporation, a hobbyist, or someone starting out learning programming could write executable code that had the same rights as anyone else’s code. Over time a trend became apparent. First drivers could be signed, loading unsigned drivers flagged a warning. The warning became much bigger in SP2 for XP. Now unsigned drivers are being refused entry completely. The situation is catching up in user mode code too. Executables that require UAC get a much friendly looking UAC prompt (blue) if they are signed, rather than orange if they are unsigned. Can we expect this trend to continue so that in a few years unsigned executables will not be allowed elevated privileges? Will this continue on until the only unsigned code a hobbyist can write is VBScript?

    We already see this situation with other computing devices. Game consoles, smart phones etc generally only run authorised code. It would be a great shame to see Windows eventually do the same. There are a variety of handy programs I run that have been written as hobbyist projects. These would simply cease to under a regime requiring everything to be signed. I would not like to see my computer becoming less useful in the name of security.

    In my mind the matter of allowing or not allowing unsigned drivers to load has far reaching implications for the future of computing. This should concern anyone who would like to be able to use their computer for what they want in 5 years time.

    Ben.

  63. William Old says:

    Wel, folks, at least you now understand the reality relating to Microsoft’s "security" – it’s a powerful marketing tool, and nothing to do with decreasing the likelihood of your PC being compromised due to the inherent insecurity of MS operating systems.

    Are you going to turn off every ATI card out there in userland, MS?  Hmmm… you’ve got a real problem now… 🙂

    Vista, and its predecessors, is technically poorly-written, and has a fundamentally-broken security model – "end of".  

    And in the UK, there’s now growing Government criticism that very little is being done to protect consumers from such scrappy software – a growing demand that software suppliers should be legally liable for the insecurity of their code.

    Sleep tight, Redmond folks!

  64. So you managed to recognized a widely advertised product and used your sheer size and power in the market to have Verisign withdraw a certificate. That sucks big time. While I also think that it is debatable whether software like Atsiv should be combatted, the way this was handled showed the ugly face of a power abusing company. Pity, I thought that times are gone but obviously, if you can’t beat them on technically everything goes

  65. Ray says:

    A primary benefit of KMCS is that it provides a means to identify the author of a piece of code, which helps enable follow-up with the author to address crashes that are observed through mechanisms such as Microsoft Online Crash Analysis

    ____________

    No. 🙂 A primary benefit is only to take more money for Microsoft and make life of developers is more hard that ever. I see no reason why I should pay 500$ each year just because you think it will be good for your customers! I can buy this stupid signature and make something bad. Why will check it? 🙂 No one because Windows will allow code such to load and run.

    The Kernel Mode Code Signing (KMCS) policy in Win64 is one of the stupid things Microsoft created for their line of Vista 64 products. This will not make OS more stable. This will force developers to spend money for nothing.

  66. Niels Madsen says:

    You have through this and other driver signing issued disabled a lot of the overclocking programs out there – thereby alienating a huge group of users who moved to this OS(i’m writing this @ Vista Ultimate 64-bit) for the promised gaming features, ever heard of double standards?

  67. sabogj@yahoo.com says:

    I would sure like to get my hands on this program.  Seems that it is no longer available???

  68. Peter says:

    "I’m uncomfortable with the idea of CA’s becoming the software police"

    Wow. Well Im unconfortable with intels truted computing and DRM.

    Random companies deciding what you can or cant do with media documents and files? combine this with CA’s deciding what programs we can actually run and what are we actually left with?

    Answer: Microsoft media player, Microsoft Word, Microsoft Excel…

    Pete

  69. TG says:

    Now, correct me if I’m wrong here, but didn’t Mr. Field just accidently admit that the KMCS is NOT a security feature?

    And that it is certainly NOT a vital part of the overall environment protecting the OS from malware?

    So why exactly is it that even power users are unable to turn this ‘feature’ off?

  70. Нов панаир около Vista. Изследователя Alex Ionescu (май имама румънски корени) е открил нов начин за зареждане на неподписани драйвери. Използва с

  71. Gabriel says:

    Where can I get Atsiv 1.01?

    Can not find it anywhere now!

  72. RLJ says:

    Sounds like a class action suit to me !!

  73. RLJ says:

    Sounds like a class action suit to me !!

  74. Orlando says:

    By all means, it has to be stopped. Consumers have to unite and sue Microsoft for this outrage!

    Redmond has gone completely crazy.

  75. Triangle says:

    "Instead, think of Kernel Mode Code Signing as default admin policy for the kernel, that the admin can change if he wants to. In analogy with my car, I’m glad that my car has airbags that deploy by default. I could disable them, if I wanted, but I generally choose not to. I suspect that the large majority of users also feel similarly about default policy on a system.

    I don’t think that kernel mode code signing changes the admin = god model in any fundamental way."

    I’m sorry, but I have to point out a fundamental difference between airbags and KMCS: Airbags actually have a chance of saving your life. Requiring code signing does not remove bugs from drivers. It does not make the system more stable. And it does not prevent malicious programs from taking over the computer by using drivers. The only thing that comes anywhere near close to stopping malicious programs is running with reduced rights*, which then means that the user has reduced rights as well, effectively turning the entire Windows experience into nothing but UAC prompts.

    The single reason for this is that Windows cannot tell the difference between a user and a program: A process automatically gains all the rights of the user account in which is runs. This inability to realize the difference puts Windows in a horrible situation: A user will want to run with the most power they can have, so that they have easy access to _their machine_ and all the hardware they attach to it. A program may be malicious or friendly, and even if friendly it may have bugs that allow it to be used maliciously. And the user will most likely want to run programs that may be exploitable. UAC, WFP, and seveal other things are little more than cheap hacks to make up for Windows inability to distinguish between the user and his or her programs. I have a hunch that once this inability is gone, a whole lot of problems that have been stressing Microsoft and Windows users will slowly dissapear. Windows has always had better usability than any other OS. Security should be able to coexist with that.

    Regarding KMCS specifically: I’ll be brief; ditch it and move the drivers into a usermode process that has access to I/O ports, but not the main kernel itself. Then if a crappy driver goes down in flames, the system doesn’t go with it.

    *I am aware of the runas utility, but a user who doesn’t know anything about Windows except how to run Media Player will never find in a million years.

  76. Not says:

    I cannot believe MS is trying kill off the x64 initative.

    Driver signing does not protect the computer.

    I have notice (as have most others) that their extremely more vulnerable and more prevalent x86 based OS does not have this new "feature". If security is such an issue Vista would have this accross the board.

    Instead MS has chosen to remove our freadom of choice.

    I have many applications that I run for testing that I cannot use now due to this ridiculous so called security feature.

    It prevents me from BETA testing many application, simple temprature monitors no longer work.

    How can they keep this crap up.

    I am disgusted with this and the removal of ANY ability on the part of the system admin to remove it.

    It is MY computer, I can install what I want and should not be force to adhere to what Microsoft feels I should install.

    The x64 OS is designed and presented for professionals not for the average user.

    Give us credit to know what we want installed.

    If driver signing was on the x86 version Vista would not be selling at all, but then again since MS is removing the choice of buying a new PC with XP from us in January I guess they are again enforing their will on us.

    Nice one guys…

  77. Brad says:

    Quit your whining like babies and do some research for crying out loud.

    Google how to install unsigned drivers in Vista 64 and you’ll find a way to work around it.

    I did and it works just fine. You bunch of blathering babies

  78. Andy says:

    Thanks Brad, I can reboot and press f8 every time I want to load a driver or I can install the test certificate, modify the registry with regedit, export the registry, sign the driver myself with the test certificate, modify the registry again to import the registry key, enable test mode and reboot my computer. Oh damn, either way I can’t listen to music or watch movies on my computer.

    If I wanted to go through this much effort I would be using Linux!

  79. Dzisiaj natknąłem się na następującą perełkę: Firma Sunbelt Software dokonała dość niemiłego odkrycia. Znane wszystkim (a przynajmniej bardziej zaawansowanym) użytkownikom Windows certyfikaty Thawte wcale nie zapewniają bezpieczeństwa.

  80. Up Yours, M$ !!! says:

    @Brad

    You idiotic piece of scum.

    If you had done as much research as the people who ended up here, then you’d know that all other bypass methods have systematically been "fixed" by Microsoft, eliminating all other VIABLE, AUTOMATED options, and this is yet one more "fix" in a clear campaign to give M$ total control of what code I run on my x64 platform, and what competitiors can develop code without fear of immediate retaliation by VeriSign and M$ revocation.  M$ puts the revocation lists into kernel code, and release in a new "security update", so that to get a fix for a bug that is a real security threat, you also must accept a denial of service attack from M$ to prevent you from running competing software on their OS.

    Security and Trust is NOT increased by forcing all developers to publicly identify themselves and be reachable for M$ spam.  I use free software.  I learn about it by researching for software that will do what I want.  I check the web site.  I may look at the source code.  I look at their forums.  I look at what other people say about the company/group/person on other sites.  Then I decide if I can trust the software.  Me.  That’s not a big security risk.

    Microsoft considers the user the biggest security threat, and seeks to eliminate the possibility of the user from making any decisions, merely because some idiots may make uninformed decisions.

    … With Liberty and Justice for All?

  81. Robin says:

    I only want to know how to disable x64 Driver Signing.

  82. John says:

    This is completely unacceptable of Microsoft to do. I now have hardware in my computer that I need for professional reasons that I can’t use because the only drivers available from the manufacturer are currently unsigned beta drivers which worked perfectly fine under Windows XP x64. So what was the point of me getting a new computer then? To think all of this is because some a-hole decided that I can’t make the right decisions for myself. This is America, not China. Now I have lost time and money because I can’t work without my hardware. Vista really is the greatest OS! (for me to poop on!)

  83. Jermo says:

    I believe MS will ultimately fix Vista x64. Sometimes it’s hard for bean counters and closet geeks (geeks that never go out in the real world) to understand the actual real world needs of their customers. I’m certain that Windows ME’s cousin "VISTA" will either be fixed quickly or dumped for Longhorn.

    I suspect Vista will get abandoned for Longhorn as fast as M$ can get it sellable. Note I didn’t say usable/viable/stable/secure..etc….

  84. TJ says:

    8. SCOPE OF LICENSE.  The software is licensed, not sold.  This agreement only gives you some rights to use the software.  The manufacturer or installer and Microsoft reserve all other rights.  Unless applicable law gives you more rights despite this limitation, you may use the software only as expressly permitted in this agreement.  In doing so,—–>you must comply with any technical limitations in the software that only allow you to use it in certain ways.<—–  For more information, see the software documentation.  *****You may not*****

    —–>· work around any technical limitations in the software;<—–

    · reverse engineer, decompile or disassemble the software, except and only to the extent that applicable law expressly permits, despite this limitation;

    · use components of the software to run applications not running on the software;

    · make more copies of the software than specified in this agreement or allowed by applicable law, despite this limitation;

    · publish the software for others to copy;

    · rent, lease or lend the software; or

    · use the software for commercial software hosting services.

  85. Wilbur says:

    As I see it there are many contentious issues surrounding driver signing.

    For me anything that protects my security is a good thing.

    Whether I have a right to decide what I want on my PC is also a good thing.

    What happens if:

    I regularly use a software package at home and i want to upgrade to Vista64, but driver restrictions say: NO, is that right: NO, I should have a choice:YES

    If I choose to use a driver that may be of danger to my system I should choose, this is my decision not MICROSOFTS.

    A possible solution would be to run every unsigned driver in a virtual world VMWare.

  86. Cluda says:

    "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."

    I’m confused about certificate revocation. #3 above indicates that the Microsoft revocation list (is this a list for cross-certificates?) is only checked at driver load time, thus a reboot is required. What about the VeriSign revocation? Is this also checked only at boot time, or more frequently?

    Also, why would you be investigating adding it to your own revocation list? If it’s good enough for VeriSign’s revocation list why would it not qualify for yours?

  87. kelsey says:

    I have MULTIPLE windows security updates dating back to 2005–are these updates piggy-backed on the recent updates..should I delete the older ones?

  88. Pelefon says:

    Hello, there.

    I am trying to find the Atsiv tool to download it, but I just cant find it.

    Can someone upload it to some filesharing host?

    Thanks.

  89. Jason says:

    Why do you insist on users pressing F8 to boot with unsigned drivers.  Why can’t you allow a setting to be set so when we have drivers that *we know* we want to use we can.  The current patched Vista is absurb!

  90. dust11 says:

    Pelefon: Atsiv cannot be executed now that Microsoft have added a rule to windows defender to stop it. Even if you found Atsiv, you’d have a hard time getting it to run. Trust me, I’ve tried.

  91. Jim says:

    Since I bought Vista Ultimate 64 because it was billed as being the be all end all of OS’s for the power user and now find out that many of the programs and hardware I want to run will not run because the drivers won’t load….who do I contact about getting a refund for Vista?

  92. darkuncle says:

    @Jim: good luck with that. Read through the EULA you "signed" for a chuckle sometime. When you feel sufficiently emasculated, go read Peter Gutmann’s "Cost Analysis of Windows Vista Content Protection" (I recommend the slides, which have been updated more recently) at http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.html. Then go read Neal Stephenson’s "In the Beginning Was The Command Line", and grab a copy of an operating system that does what YOU tell it, rather than the other way around.

  93. bobbuilder says:

    Allow users to always boot with driver signatures disabled.  Who can remember to hit F8 every time they reboot?  This is absurd!

  94. dude says:

    there has got to be some stupid work around, good thing we are sheep

  95. Rick says:

    Cool beans (or not). This feature, to a certain extent, with SP1 is coming to the 32-bit world:

    http://forums.microsoft.com/TechNet/ShowPost.aspx?PageIndex=3&SiteID=17&PageID=3&PostID=2732860#2732860

  96. Kai Robinson says:

    Okay – you’ve put driver signing in x64 Vista. Okay, fine with me, but for the love of all thats holy – WHY did you have to do something monumentally stupid and REMOVE the ability of the end user to IGNORE driver signing? Seriously – its not like average joe end users have x64, and if they DID you can bet your life they wont bother with using something ‘complex’ (ho ho ho) as a command line instruction (BCDEdit).

    Give us the ability to TURN THIS CRAP OFF if we want to! Either re-instate BCDEdit or allow changes to the group policy! I want to be able to run ATITool and other applications like CoreTemp – small developers cannot afford and/or do not want to be ‘registered’ by microsoft or have their software inspected and ‘signed’ for use. Who are YOU to dictate what *I* can and can’t run on my machine?

    We pay an extortionate amount for such a badly designed and implemented OS as it is – taking more and more away from the end user only ends up making YOU, the software designers look like a bunch of poo-flinging apes.

    Myself? I’m using a STABLE and UNOPPRESSIVE operating system. Windows XP x86-64 – thats right, XP64. Why, oh WHY did you have to bury this wonderful OS (with NO WGA! Yay!) with the giant steaming turd that is Vista?

    Then again, had it gone properly mainstream, you’d have found a way to bugger it up….i suppose its just as well MS forgot about it…

  97. Jim Sura says:

    My Vista64 Ultimate has for some unknown reason decided to stop loading the microsoft WPD driver and the esata promise300tx2 driver. Every time the pc is shutdown i have to disable then enable the drivers to get it to load and the wpd prob makes me have to en/dis for each type of card individually!

    Googling this, one thread said sp1 fixed this. As the gentleman above (Kai) said I like to run rivatuner and any nvidia driver releases for my top end system and coretemp and my maximus mb updates. If i install sp1 much of my system will not function THE WAY I WANT IT TO. good thing my 42 inch westy doesnt need its own signed driver!

    Why dont you give a key via update to validated copies who request driver signing_disable via a checkbox with the dload!! and encrypt it into the activation code on an individual basis? If you dont implement something God will be p’od and then…

     Steve Jobs ought to copy and vlite your os and release an OS that runs on my system with the drivers i choose to karmically balance history. The courts will keep ya all bizzy fighting until some 15 yr old genius bypasses your third chakra power trip next week..quit fighting and join the family…too few years on the planet for conflict.

    Yours truly,(Jim Sura, PhD ChemEng 64 years old)

  98. Jim Sura says:

    My Vista64 Ultimate has for some unknown reason decided to stop loading the microsoft WPD driver and the esata promise300tx2 driver. Every time the pc is shutdown i have to disable then enable the drivers to get it to load and the wpd prob makes me have to en/dis for each type of card individually!

    Googling this, one thread said sp1 fixed this. As the gentleman above (Kai) said I like to run rivatuner and any nvidia driver releases for my top end system and coretemp and my maximus mb updates. If i install sp1 much of my system will not function THE WAY I WANT IT TO. good thing my 42 inch westy doesnt need its own signed driver!

    Why dont you give a key via update to validated copies who request driver signing_disable via a checkbox with the dload!! and encrypt it into the activation code on an individual basis? If you dont implement something God will be p’od and then…

     Steve Jobs ought to copy and vlite your os and release an OS that runs on my system with the drivers i choose to karmically balance history. The courts will keep ya all bizzy fighting until some 15 yr old genius bypasses your third chakra power trip next week..quit fighting and join the family…too few years on the planet for conflict.

    Yours truly,(Jim Sura, PhD ChemEng 64 years old)

  99. Daniel says:

    Let MS bleed customers and money. Everybody knows why Bill Gates really left and left Steve Ballmer in charge. When the company goes down, it’s obviously because Bill left, but that’s OK, because he’s hanging out with Bono and acting as a God to third-world countries.

  100. Kai Robinson says:

    I’m still waiting for some form of official comment with regards to allowing unsigned drivers to be run on x64 without having o resort to pressing F8 on bootup….come on Scott, have you gone silent on us?

  101. Michael from Australia says:

    Loading unsigned drivers within VMware is all good and well, but what has got me here is that I cant even install VMware – because it’s 64 bit networking drivers are UNSIGNED!!

    I bought a computer with 8GB memory, for virtual computing. I bought Vista Ultimate x64, for virtual computing. And guess what. I cant.

    Microsoft have well and truely screwed me over, yet again.

    Isn’t interesting how in vista we have lost "MY COMPUTER" and now it’s just "COMPUTER". Soon it will be "MICROSOFTS COMPUTER" – this is becoming quite a joke.

    I now live with 2 computers, one for Vista and what microsoft lets me do on it, and my older one with XP, for all the hardware I have, that Vista wont support as the drivers are unsigned.

    Plus – even if I was installing potential MalWare – hold on – its my choice – if I am the idiot wanting to stuff up my system, I’ll just get out my Windows CD and re-install. But wait. No. Cant do that either. It will probably deny me re-activating the software. Now that’s another story altogether….

    ARRRRRGGGHHHHH!!!!

  102. Joey says:

    Cant’ anyone sue MS for this so they are by law forced to provide a "turn off" functionallity? I can’t either install VMWare on Vista x64 due to "unsigned drivers". Well, thank you Vista for informing me about unsigned drivers but still it’s my choice to continue or not!!

    Anyway got rid of Vista and running Linux now, will try to avoid MS products in the future an hopefully live longer. 🙂

  103. Malik says:

    This is rather disappointing, I can echo the same comments about VMWare and being unable to use it on my own machine.  The sad part about this is that there is not even a known "Super User" or "developer" hack or method of bypassing this (and yes I am aware of running the kernel in debug mode option, that is hardly an option for day to day usage).  I would like to see a response from Microsoft as to why is it that driver signing is an absolute requirement on x64 Vista?  Why is it not a requirement as such on x86?  Why is there no way for users to use their own system the way they choose?

    More and more it seems that Microsoft is trying really hardly to loose their edge in the OS market.  Companies are already not deploying vista because of all the problems that it creates for them and now Microsoft makes an active and irresponsible approach towards making sure that people have no way of using their hardware.

    This is sad and frustrating indeed … so much for corporate governance!

  104. Harvey says:

    Have just purchased Vista Ultimate 64bit and loaded onto new machine with all the bells. Guess what it will not allow me to go on the internet because it cannot see the network. So I have a machine that will not update I cannot use for my normal work. Thanks Mr Gates and Microsoft you have lost me and I have lost money and time how about you shove your window os where the sun will not shine and give everybody their money back.

  105. concerned says:

    I have a copy of Atsiv and it’s still working and allowing me to use my unsigned drivers on Vista 64. I just disabled Windows Defender to make sure it didn’t delete it. If I wanted a dummy OS I would use a Mac! If M$ continues to prevent me from running my software I’ll make Ubuntu to my primary OS. Security is good but I think M$ overstepped the mark on this one – hopefully Vista will teach M$ a lesion on equilibrium.

  106. Richard FDisk says:

    I found this while searching for the name of the executable for the Win Me system restore so I can delete it (actually rename it to *.ex_) with a startup command so it happens before the WFP / FPS

    I haven’t bothered with vi$ta because of the restrictive nature in what I can / CAN’T do with the pc

    here’s the real issue:

    the computer (which I paid for and therefore own) hosts the OS, not the other way around

    M$ thinks it’s the OS that host the computer, just reading the EULA alone reveals this.

    in case anyone forgot that M$ is moving toward the "Subscription" model type of OS, where all you own is a box with your data files and the O$ & "Approved programs" will run directly from the host WWW server where ever they are, be it in Redmond or elsewhere and no local programs will be allowed to execute.

    and on and on it goes…

    too bad though that most people will go for this rather than bother to play with another OS that might be a bit more difficult to set up and use.

  107. Linux next? says:

    Whats next? A software package from MS provided with the OS and a MS labeled outfit to wear when sitting behind the MS configured machine? MS can state in their rules that only software approved by them may run on MY computer (Not alone state, also prohibit),  but it only results in me throwing the expensive bought MS Product CD into the trash bin. I bought my computer to run apps, games and software I think I need to run. Reinstalling other OS is the first thing I am about to do after 5 hours of finding a solution to install a simpel app, MS is over and done for me and as I hear also for many, many others! I’ll even throw in all the MCSE, MCSA, MCSD certificates I gained over the (untill recently) loyal years I sadly wasted. Next buisiness advice I’ll give won’t be the same. If I would like people to boss me around what I can or can’t do on MY own hardware, I’ll move to the ChinaWideWeb…

    Please don’t mind my poor English.

    Grtz,

    An ex MS user.

  108. 247Blogging says:

    Hi, it’s Scott Field, Windows Security Architect, again. Microsoft recently became aware of a third party kernel mode driver named “Atsiv” which provides a deliberate means of loading code that conflicts with the Kernel Mode Code Signing (KMCS) polic

  109. Dating says:

    Hi, it’s Scott Field, Windows Security Architect, again. Microsoft recently became aware of a third party kernel mode driver named “Atsiv” which provides a deliberate means of loading code that conflicts with the Kernel Mode Code Signing (KMCS) polic

  110. Weddings says:

    Hi, it’s Scott Field, Windows Security Architect, again. Microsoft recently became aware of a third party kernel mode driver named “Atsiv” which provides a deliberate means of loading code that conflicts with the Kernel Mode Code Signing (KMCS) polic

  111. brian says:

    the software should stop unsigned third party drivers from being installed.  this is essential for security concerns.

  112. Matt says:

    no its not!

    Signed drivers may be just as malicious as unsigned and has nothing to do with security, just another way for MS to steal even more money.

    What? did you think getting a driver signed is free?

  113. Gman LoadaShit DRM says:

    Look, I see what this guy is sayingh and it explains many of the problems we are having with our Vista OS 64X systems. If your system jas any unsigned drivers it’s going to dump them straight away. Ever wonder where those drivers went. Hmm, seems to me if I wish to run a program and load it mysewlf then it’s my problem if the drivers are safe or not… M$ and the rest of you A wholes get5 out of our living rooms, PLEASE! WE aren’t all idiots!

  114. Fduch says:

    rk is a liar.

    My boss made a mistake of buying Vista x64 SP1 and now he cannot connect use internet because Vista soen’t allow him to install drivers for hist Auslinx AL2006 ADSL modem.

    What are step-by-step instructions to use the software and hardware he BOUGHT? The instrustions, not the usual lies.

  115. Rob says:

    Scott,

    I can understand where both you are coming from, as well as this now disgruntled section of your user base.  They feel like they should be able to run whatever they want on their computer, and it doesn’t affect anyone else.  That idea is fundementally flawed, if lets their computer get root-kitted or unknowingly becomes a member of a bot-net they are affecting many other users.

    This said, there will always be those who want to run unsigned drivers, and a tool like Atsiv that allows them to do that actually serves as a protection for you.  Right now their options are to:

    1- not be able to run unsigned drivers- just move on (some will but not many)

    2- sign their own drivers and run them in test mode (which for the complainers does NOT require the user to purchase a certificate)- but is difficult even for many of the self-proclaimed advanced users here- but provides a viable option for researchers and hobbiests.

    3- Turn off integrity checks completely.  This is the option most users will take without Atsiv; thus to load one unsigned blue-tooth driver, all driver signing security is turned off- and the computer is left worse off than when the Atsiv hack was being used.

    My suggestion would be for Microsoft to provide a way for these users (not just the super advanced) to load the drivers they choose- but not make it easy enough that grandma could do it (defeating the push for driver signing).

    On the other hand, keeping something like Atsiv around allows you to take a stand completely for driver-signing while allowing more experienced users an unsupported way around it (which is better than totally turning it off).

    I think the Windows defender signiture is both necessary and sufficient.  Atsiv (or anything like it) should not run unknowingly on someone’s system, but the choice to run it should still be theirs.

  116. nad says:

    > Isn’t interesting how in vista we have lost

    > "MY COMPUTER" and now it’s just "COMPUTER".

    > Soon it will be "MICROSOFTS COMPUTER" – this

    > is becoming quite a joke.

    LOL… that made me laugh because it is so true!

    Of course everyone has the option to not install Vista. What’s wrong with XP x64?

    Anyway, it’s reasons like this that my employer isn’t upgrading to Vista on any of their 3000+ machines. If they can’t smarten up, at least for business users, then we’ll all be in an interesting situation come a few years.

  117. Dale says:

    Well, I am considering installing SP1 on my Vista X64 but I’m worried about losing the ability to run the unsigned VMWare Server drivers.  Currently, I am able to run them by pressing F8 during the boot cycle and selecting to disable unsigned driver checking.  Is SP1 going to break that?

  118. Tom Anderson says:

    Actually, I’ve got Vista Ultimate x64 w/sp1 install on my main system, and I confirm now that SP1 does NOT break the ability to do the "unsigned driver" thing that Dale just mentioned.

    SP1 doesn’t really do much to help the situation either. Maybe with vista sp2 m$ will actually implement the ability to more easily shut off driver verification, even in Ultimate, being the user’s choice.

  119. 41L3F says:

    i am on vista 32 bits and in 1 min i’m going to install vista 64 on some xps M1330,

    i’m fed up to fight every minute cause all my machines are connected 24h/24.

    so i decided to test this 64 bits, the fact that there’s no way to crash the system with coders that not a little time totally killed the system cause they wanted high privileges so what we got with that ?

    applications full of exploits to make easier the work of the lamers, now i’m fed up with all those codes that are released by thousands each day to contaminate systems,

    the AV prooved their incapacity to be a guardian for the system, do u know how easy it is to bypass most of AV, just look at google and type bypass AV, u’ll see that packagers used defeat the possibility for the AV to scan so it says no malware except if u trust one AV, u’re dead, go to virustotal.com and then u see that your clean file is detected by 15-16 engines on 36 and all your AVs are just the biggest joke ever, so now with the situation, i’m going to try this 64 bits, if no code can modify the kernel, that’s a great new, why didnt they do that with vista 32? myabe to be more compatible with all the xp 32, and about the drivers and digit sign 2048 bits, like it’s nothing to be sure that u’re installing some driver 100% sure , if u are not happy go back to vista 32, but they day u’ll face some great rootkit, the one that goes directly into the kernel and control all your system and even when u turn off your machine it goes into the bios in the acpi, so when u turn on the code allready controls what will happen before u can see the vista load page.

    and those type of rootkits if u think that u can clean them for sure at 100%, u dream completly, the solution is just to start with some new vista 32 but how long will it take before it will be virused?

    what i hope is that this situation with malwares going out every minute will have a low impact on the 64 bits version.

    and yes i want digit sign and not a coder to touch the kernel, i know they can offer for all BSOD all the time.

    now it’s time to take new position cause we cannot fight vs all those exploits that will kill your 32 bits like all MS OS.

    if u don’t understand that for some people the most important is to be sure of the code they install and to completly lock the kernel, that way people that code with feets will never have the possibility to completly mess a system in 30 seconds.

    now i’ll see if this solution can help to prevent the massive attack of malwares for last years.

    advice : dont trust your AV, always us virustotal.com, use comodo FW DEFENSE+ 3.5 for prevention and some powerfull filter for the web, change your dns cause  the machines infected the time i wrote are certainly more than 10 000.

    i hope the MS way to secure the OS will satisfy me but i’m fed up to fight with security every minute.

    who can tell he sure at 100% his pc is safe? no one, but u hope it is.

  120. Flug says:

    If I were you,  skimming through the comments would make me upset, guys. Just listen to your clients and users as their critics are crucial for your survival.

  121. Micah says:

    Basically in the current design there are two options:

    1) Run drivers only by companies that can afford the $500 / year Verisign certificate.

    2) Press F8 every time your computer boots up and sacrifice the whole driver signing security system by allowing any driver to load on the system.

    Obviously the problem with #1 is when I want to run a very useful tool by Some Guy who wrote it in his free time 2 years ago and is giving it out for free.  Some Guy isn’t going to spend $500 / year indefinitely so people can continue using his freeware, instead he is going to stop writing useful tools.

    The problem with #2 is two-fold.  First off is the obvious annoyance of having to hit F8 every time you boot.  Most people will forget and end up spending far more time restarting their OS than otherwise because they want to run a certain program and they didn’t press F8 when Windows Update restarted their computer.

    Beyond just a horrific user experience though is the problem with the all-or-nothing security model.  Why is there no option to allow just one driver that I am asserting is valid?  I can understand the desire to discourage users from using unsigned drivers but when the only other option is to fully disable the security system you are left with two bad choices.

    My suggestion, offer an option for self-signing that doesn’t require a watermark, several tools and several restarts to use.  Give advanced users a way of allowing unsigned drivers on a case-by-case basis.  Ideally it would be an option somewhere that, instead of not loading the driver at all, would prompt you on first load if it’s a driver that you are familiar with.   If it is the user could accept the driver at which point it would be self-signed and windows would accept it as a signed driver from that point forward.

    This solution offers the security of driver signing without the rigidity that leads people to disable / hack the whole system.