Microsoft Security Bulletin (MS00-024): Frequently Asked Questions

What's this bulletin about?
Microsoft Security Bulletin MS00-024 announces the availability of a tool that eliminates a vulnerability posed by inappropriate permissions on a registry key in Microsoft® Windows NT® 4.0. The default permissions on this key could allow a malicious user to compromise other users' cryptographic keys. Microsoft is committed to protecting customers' information, and is providing the bulletin to inform customers of the vulnerability and what they can do about it.

What's the scope of the vulnerability?
This vulnerability could allow a malicious user to install modified cryptographic software on a machine that he could log onto interactively. The modified software potentially could compromise the cryptographic keys of users who subsequently used the same machine.
The machines primarily affected by this vulnerability would be workstations and terminal servers. If standard security recommendations are followed, security-critical servers such as web servers, domain controllers, database servers and others would not allow normal users to log onto them interactively. Windows NT auditing could be used to determine that the user had made the changes to the registry.

What causes the vulnerability?
This vulnerability results because the default permissions on a registry key in Windows NT 4.0 are too loose. The permissions should only allow administrators to change the value of the key, but they actually allow normal users to change the value as well

What is the key?
The key at issue here is HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography\Offload. This key is used by OffloadModExpo(), a function available for CryptoAPI CSPs to use when calling hardware accelerators to perform modular exponentiation.

What is CryptoAPI?
CryptoAPI is a technology provided as part of Windows® 95, 98, Windows NT, and Windows 2000. It provides a standard way for applications to obtain cryptographic services such as encryption and decryption, digital signing, and so forth.

What is a CSP?
In CryptoAPI, software modules called Cryptographic Service Providers, or CSPs, provide the actual cryptographic services. All Microsoft platforms provide a default set of CSPs that provide basic cryptographic functions, known as the Base CSPs. The Base CSPs provide services such as encryption using RSA and DES, digital signing using DSA, and secure hashing using MD5 and SHA-1. Vendors can develop additional CSPs, and these can be "plugged into" CryptoAPI to provide other cryptographic services.

What is a hardware accelerator?
In general, a hardware accelerator is any piece of hardware that is designed to perform a computation in place of software. As a rule, special-purpose hardware can perform computations much faster than software. In cases where performance is crucial, the cost of dedicated hardware may be worth the improved performance it provides.

What is modular exponentiation?
Modular exponentiation is a mathematical operation that is at the heart of public-key cryptography. It consists of raising a number to a power, then taking the modulus of the result with respect to another number. Most public-key cryptoalgorithms involve the use of modular exponentiation.
Modular exponentiation is very computationally-intensive operation, and is rather slow when performed in software. As a result, hardware accelerators are frequently used to improve the throughput of machines that perform a high volume of cryptographic processing.

What does the OffloadModExpo() function do?
OffloadModExpo() is a function provided as part of the CryptoAPI CSP Developers Kit. It allows a CSP to use a hardware accelerator in order to improve the speed with which modular exponentiation can be performed. More information on the OffloadModExpo() function is available at http://msdn2.microsoft.com/fr-fr/library/aa387021.aspx.
If a CSP is designed to accommodate a hardware accelerator, it uses the OffloadModExpo() function to request services from the accelerator. Before doing so, though, the name of the driver DLL for the accelerator must be provided via the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography\Offload\ExpoOffload value. The driver software is specified via the registry key because there are many hardware accelerators available, each with its own driver software, and the administrator needs a way to specify the specific one that is installed on the machine.

Why would a hardware accelerator have access to cryptographic keys?
A hardware accelerator that performs modular exponentiation would require access to the keys in order to do its job. The keys are used within the modular exponentiation operation as part of the process of encrypting or decrypting data.

Is this a vulnerability in CryptoAPI?
No. The vulnerability is present simply because of inappropriate permissions on a registry key. When the correct permissions are applied, the vulnerability is eliminated.
In addition, it's worth pointing out that the OffloadModExpo() is not an inherent feature provided by CryptoAPI. It's a function that CSPs can use if desired, but it's not used by all CSPs. If a CSP doesn't use OffloadModExpo(), it doesn't matter what value, if any, the registry key has.

What are some CSPs that use OffloadModExpo()?
The Base CSPs provided as part of all Microsoft platforms use OffloadModExpo()and are therefor affected by this vulnerability.

What are some CSPs that do not use OffloadModExpo()?
The Smart Card CSP provided as part of Windows 2000 is an example of a CSP that does not use OffloadModExpo()and is therefore not affected by this vulnerability.

How would a malicious user exploit this vulnerability?
The malicious user would need to develop his own DLL that poses as the driver for a hardware accelerator, but compromises keys - by storing them for later retrieval, sending them to the malicious user, etc. He would then need to log onto a machine interactively, save his bogus DLL on the machine, and add the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\
Cryptography\Offload\ExpoOffload value to specify his DLL as the driver for a non-existent accelerator. If another user subsequently logged onto the same machine and performed any operation that used an affected CSP, his keys would be sent to the bogus DLL.

Would the user notice that something was wrong?
Not necessarily. It would be possible for the malicious user to write a fully-functional DLL that actually performed the expected operations, while also making a copy of the keys. However, even if the malicious user simply wrote a "stub" that copied the keys and ended in failure, there might not be an indication to the user that there was a problem. This is because of the way the Base CSPs operate. If the Base CSPs send a value to a hardware accelerator via the OffloadModExpo() function and receives a return code that indicates failure, it assumes that the hardware card has failed and performs the operation in software.

Would I need to have a hardware accelerator in my machine to be affected by this vulnerability?
No. CSPs don't communicate directly with the hardware - they communicate with the driver software, which then communicates with the hardware. As long as there is a driver specified that responds as expected, the CSP wouldn't have any way to know whether there actually is a hardware accelerator on your machine or not.

CSPs are always digitally signed. Wouldn't the bogus DLL need to be signed as well?
No. By design, the default CSPs do not require that the driver DLL for hardware accelerators be digitally signed. At first blush, this may seem inconsistent with the fact that the CSPs themselves are signed. However, it's important to keep in mind that the purpose of signing the CSPs is to ensure export control compliance, not to provide security.

What do you mean by "the purpose of signing the CSPs is to ensure export control compliance, not to provide security"?
As a US company, Microsoft is bound by US export control laws, including those that apply to cryptographic export. Because CryptoAPI is an enabling technology for cryptographic products, Microsoft is required to make reasonable efforts to ensure that any CSP that uses it also complies with US export control laws. We do this by digitally signing CSPs. When a vendor develops a CSP, Microsoft verifies that the appropriate export licensing has been completed, then signs the CSP. CryptoAPI will only allow CSPs signed by Microsoft to load and run.
However, not all products associated with cryptography are export-controlled. For instance, a hardware accelerator might not be subject to export controls, as long as it only improved performance without changing the cipher strength. There would therefore be no reason why the DLL for such a product would need to be signed, and no reason why it would be inappropriate for a signed CSP to call an unsigned DLL.

Could this vulnerability be exploited accidentally?
No. Exploiting the vulnerability would require that the malicious user write custom software specifically for the purpose of compromising the keys, and take deliberate action to modify the registry value.

If someone changed the value of the registry key, could I tell who did it?
Yes. Windows NT 4.0 auditing would show who made the change and when.

Could this vulnerability be exploited remotely?
No. The Winreg registry key regulates whether registry keys can be remotely accessed. By default, it denies remote access to all but a few exceptions, which are discussed in KB article 153183. The affected registry key is not among the exceptions, and therefore could not be accessed under default conditions.

What machines are primarily at risk from this vulnerability?
The machines primarily at risk from this vulnerability would be Windows NT 4.0 workstations and terminal servers, as normal users typically are allowed to log onto these machines interactively. If standard security recommendations have been followed, normal users will not be allowed to log onto security-critical machines like domain controllers, database servers, web servers, ERP servers, print/file servers, and the like, and they would not be affected by this vulnerability.

Does this vulnerability affect Windows 2000?
No. The permissions for HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography\Offload are correctly set by default in Windows 2000.

Does this vulnerability affect machines that have been upgraded from Windows NT 4.0 to Windows 2000?
No. As part of the upgrade from Windows NT 4.0 to Windows 2000, the appropriate permissions are set.

Are there any conditions under which a Windows NT 4.0 machine would not be affected by this vulnerability?
Yes. The secure workstation/server Security Configuration Manager template provided with Windows NT 4.0 (securws4.inf) sets the correct permissions on the key. If you've used this template to secure your Windows NT 4.0 machines, you are not at risk from this vulnerability.

Where can I get the tool?
The download location for the tool is provided in the "Patch Availability" section of the security bulletin 

What machines should I run the tool on?
The tool can be run on any machine. However, the machines that will benefit most from this tool are those that allow unprivileged users to log on interactively.

Does the tool do anything besides eliminating this vulnerability?
Yes. In addition to correcting the permission on the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography\Offload registry key, it also incorporates the functionality of the tool provided in Microsoft Security Bulletin MS00-008. By using this tool, customers can ensure that all known vulnerabilities involving registry permissions have been eliminated.

How do I run the tool?
The tool can be run interactively or from a script, against either the local machine or a remote one. The usage is:

If -v is specified, information is returned regarding the processing of each key.
If -m is specified, a remote computer name must be provided on the command line. You must currently be logged in with an account that has administrative privileges on the remote machine, or you must have previously established a session with the target machine under such credentials. This can be done, for example, by "net using" to IPC$ and providing the proper credentials.

Do I ever need to re-run the tool?
You only need to re-run the tool if you perform an operation that resets any of the permissions on one of the affected registry keys.

How can I tell if the tool ran correctly?
Complete instructions for using the tool and interpreting the return codes are provided in the Knowledge Base article. However, if the verbose option (-v) is used, the tool will indicate whether each individual key was secured successfully. In addition, the tool will provide a return code of 1 if any key could not be set, or 0 otherwise. You can also manually verify that the tool ran correctly by using regedt32 and verifying that the registry permissions are as shown in the table below.

What is Microsoft doing about this issue?

Where can I learn more about best practices for security?

The Microsoft TechNet Security web site is the best to place to get information about Microsoft security.

How do I get technical support on this issue?

Microsoft Technical Support can provide assistance with this or any other product support issue.

THE INFORMATION PROVIDED IN THE MICROSOFT KNOWLEDGE BASE IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND. MICROSOFT DISCLAIMS ALL WARRANTIES, EITHER EXPRESS OR IMPLIED, INCLUDING THE WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. IN NO EVENT SHALL MICROSOFT CORPORATION OR ITS SUPPLIERS BE LIABLE FOR ANY DAMAGES WHATSOEVER INCLUDING DIRECT, INDIRECT, INCIDENTAL, CONSEQUENTIAL, LOSS OF BUSINESS PROFITS OR SPECIAL DAMAGES, EVEN IF MICROSOFT CORPORATION OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. SOME STATES DO NOT ALLOW THE EXCLUSION OR LIMITATION OF LIABILITY FOR CONSEQUENTIAL OR INCIDENTAL DAMAGES SO THE FOREGOING LIMITATION MAY NOT APPLY.

Top of page