Microsoft Security Bulletin (MS00-008): Frequently Asked Questions
What's this bulletin about?
Microsoft Security Bulletin MS00-008 announces the availability of a tool that eliminates vulnerabilities posed by several registry keys in Microsoft® Windows NT® 4.0. The default permissions on these keys could allow an unprivileged user to take unauthorized actions on an affected machine. Microsoft is committed to keeping customers' information safe, 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?
There are three registry keys at issue here:
| • | The "AEDebug" key. The permissions on this key could allow a malicious user to run arbitrary code in a System context |
| • | The "User Shell Folders" key. The permissions on this key could allow a malicious user to specify code that would run the next time a user logged onto the machine. |
| • | The "DataFactory" key. The permissions on this key and a companion key could allow a malicious user to disable the protection against a previously-reported vulnerability affecting Microsoft Internet Information Server. |
Under default permissions, neither the "User Shell Folders" nor the "DataFactory" keys could be modified remotely unless the machine had been specifically configured to allow it. This greatly limits the scope of this vulnerability in these cases, because it means that the malicious user would need to be able to interactively log onto the machine that he or she wanted to attack. Windows NT auditing could be used to determine what user had made the changes to any of these registry keys.
What is the "AEDebug" key?
The "AEDebug" key is HKEY_LOCAL_MACHINE\Software\Microsoft\
Windows NT\CurrentVersion\AeDebug
The "AEDebug" key is intended to allow an administrator to specify a remote debugger that will be invoked as a diagnostic measure in the event of a system crash. The debugger runs in a highly-privileged state. This vulnerability results because normal users can modify the values that specify what code runs as the debugger and whether it fires automatically upon a system crash. A malicious user could specify code of his or her choosing as the debugger, then cause a system crash through some means in order to cause it to launch.
Microsoft Knowledge Base article 103861 provides more information on this key and its intended use.
What is the "User Shell Folders" key?
The "User Shell Folders" key is HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\
Windows\CurrentVersion\Explorer\User Shell Folders
The "User Shell Folders" key provides information on the location of various folders that all users of a single machine will share. Among its subkeys is one that specifies a common startup folder. This key should be accessible only to administrators, but the permissions allow normal users to set its value as well. A malicious user could change the Common Startup key to a folder that contains malicious code, in order to cause that code to run the next time a user logged onto the machine.
Microsoft Knowledge Base article 185590 provides more information on this key and its intended use.
What is the "DataFactory" key?
What we are referring to as the "DataFactory" key is actually two keys associated with the Remote Data Services in the Microsoft Data Access Components. These include:
| • | HKEY_LOCAL_MACHINE\SOFTWARE\ |
| • | HKEY_LOCAL_MACHINE \SYSTEM\CurrentControlSet\ |
These keys determine the security measures in place for database services, including those discussed in Microsoft Security Bulletin MS99-025. Because their values can be changed by unprivileged users, these users could disable the security measures. It's worth noting, though, that the particular vulnerability discussed in MS99-025 involved web servers, so a malicious user would need to be able to interactively log onto the server in order to disable the security measures. Best practices militate strongly against allowing normal users to interactively log onto security-sensitive machines like web servers.
Microsoft Knowledge Base article 184375 provides more information on these keys and their intended use.
What kind of access would a malicious user require in order to attack a machine via this vulnerability?
Under most conditions, remote users cannot change registry keys, regardless of the permissions on them. (For more information on restricting remote access to the registry, see the discussion below regarding the "Winreg" registry key). Because of this, the "User Shell Folders" and "DataFactory" keys could not be remotely accessed. (And even if the defaults were changed to allow remote access, the "User Shell Folders" vulnerability could only be exploited if the malicious user also had the ability to install software of his choice on the target machine). By default, the "AEDebug" key could be remotely accessed, but applying the tool will prevent this.
Does the tool reset the permissions on any other keys?
Yes. It recursively sets all subkeys of the affected keys to the same permissions as the main keys.
The tool also ensure that the permissions on the "Winreg" key are correctly set. The "Winreg" key is:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\
Control\SecurePipeServers\winreg
The default permissions for this key are correct, and the tool sets them only as a safety precaution.
What does the Winreg key do?
The Winreg key determines whether registry keys can be remotely accessed. By default, this key is configured to prevent users from remotely accessing most keys in the registry, and only highly-privileged users can modify it. It's worth noting, however, that because some services require remote access to the registry, there is a short list of exceptions to this rule. Knowledge Base Article 153183 discusses these exceptions, one of which would allow the "AEDebug" key to be remotely accessed.
Why does the tool check the permissions on the "Winreg" key?
If a malicious user had previously exploited the inappropriate permissions on one of the three registry keys discussed above, he or she might use the newly-gained privileges to modify the "Winreg" key. By doing so, the malicious user could ensure that he or she would be able to remotely access the registry, thereby making future attacks easier. The tool ensures that, in the event that this has happened, the malicious user's access to the registry is removed.
What are the specific permissions set by the tool?
The tool sets the following permissions on the following keys and their subkeys:
| Hive | Key | Permission |
HKEY_LOCAL_ | Microsoft\Windows NT\ | Authenticated Users: Read |
HKEY_LOCAL_ | Microsoft\Windows\ | Authenticated Users: Read |
HKEY_LOCAL_ | Microsoft\DataFactory | Authenticated Users: Read |
HKEY_LOCAL_ | CurrentControlSet\ | Authenticated Users: Read |
HKEY_LOCAL_ | CurrentControlSet\ | Administrators: Full |
Is Windows 2000 affected by the vulnerability?
No. The default permissions for these keys in Windows 2000 are the appropriate ones.
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.
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:
| • | regacl40 [-v ] [-m remotecomputername] |
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?
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 above.
What is Microsoft doing about this issue?
| • | Microsoft has developed a patch that eliminates the vulnerability. |
| • | Microsoft has provided a security bulletin and this FAQ to provide customers with a detailed understanding of the vulnerability and the patch. |
| • | Microsoft has sent copies of the security bulletin to all subscribers to the Microsoft Product Security Notification Service, a free e-mail service that customers can use to stay up to date with Microsoft security bulletins. |
| • | Microsoft has issued Knowledge Base articles explaining the vulnerability and patch in more detail. |
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.
