x64 Driver Signing Update

**z3r010** · 08-03-2007

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.

Source:- Windows Vista Security : x64 Driver Signing Update

08-03-2007	#1 (permalink)
z3r010 BOFH	x64 Driver Signing Update 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. Source:- Windows Vista Security : x64 Driver Signing Update

Thread Tools
Show Printable Version Email this Page
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Disable Driver Signing?	talon191	General Discussion	10	04-14-2008 03:04 PM
Windows x64 driver signing	Jerry MAY	Vista General	3	03-16-2008 07:22 AM
Driver Signing	Kurt Harriger	Vista security	7	04-30-2007 11:35 PM
Update on Vista Driver Signing Bypass	EU XP user	Vista security	4	01-30-2007 10:54 PM