Microsoft Security Bulletin MS02-003 - Low
Exchange 2000 System Attendant Incorrectly Sets Remote Registry Permissions
Published: February 07, 2002 | Updated: May 09, 2003
Originally posted: February 07, 2002
Updated: May 09, 2003
Who should read this bulletin: System administrators using Microsoft® Exchange 2000.
Impact of vulnerability: Less Secure Default Settings.
Maximum Severity Rating: Low
Recommendation: Administrators should apply the patch.
- Microsoft Exchange Server 2000
The Microsoft Exchange System Attendant is one of the core services in Microsoft Exchange. It performs a variety of functions related to the on-going maintenance of the Exchange system. To allow remote administration of an Exchange Server using the Exchange System Manager Microsoft Management Console (MMC) snap in, the System Attendant makes changes to the permissions on the Windows Registry to allow Exchange Administrators to remotely update configuration settings stored in the Registry.
There is a flaw in how the System Attendant makes these Registry configuration changes. This flaw could allow an unprivileged user to remotely access configuration information on the server. Specifically, this flaw inappropriately gives the "Everyone" group privileges to the WinReg key. This key controls the ability of users and groups to remotely connect to the Registry. By default, only Administrators are given the ability to remotely connect to the Registry, by granting permissions on this key.
The flaw does not grant any abilities beyond the ability to connect remotely. However, an attacker's ability to make changes to the Registry once they have successfully connected would be dictated by the permissions on the specific keys within the Registry itself. Thus, while this vulnerability does not itself give an attacker the ability to change Registry settings, it could be used in conjunction with inappropriately permissive registry settings to gain access to, and make changes to a systems Registry.
- The vulnerability only grants the ability to connect to the Registry remotely. It does not weaken any other permissions in the Registry.
- An attacker's ability to connect to the Registry remotely requires the ability to send SMB traffic to and from the target system. Firewalling best practices recommends closing the ports that NetBIOS and Direct Host uses (tcp ports 139 and 445)
|Internet Servers||Intranet Servers||Client Systems|
|Exchange 2000 Server||Low||Low||None|
The above assessment is based on the types of systems affected by the vulnerability, their typical deployment patterns, and the effect that exploiting the vulnerability would have on them. For Internet exposed systems, the best practices of blocking tcp ports 139 and 445 at the firewall prevents remote access to the registry. While there is a potential for allowing data to be compromised, there are significant mitigating factors.
Vulnerability identifier: CAN-2002-0049
Microsoft tested Exchange 5.5 and Exchange 2000 to assess whether they are affected by these vulnerabilities. Previous versions are no longer supported, and may or may not be affected by these vulnerabilities.
Frequently asked questions
What's the scope of the vulnerability?
This vulnerability could allow unprivileged users to remotely access configuration information on an Exchange 2000 server. In the worst case, this could enable an attacker to change configuration settings on the server. The vulnerability is subject to several mitigating factors:
- It only provides an attacker with the ability to access the configuration. The permissions on the specific configuration values would determine whether it would be possible for the attacker to take any action on them.
- Normal firewalling practices, if followed, would prevent an attacker on the Internet from exploiting the vulnerability.
What causes the vulnerability?
The vulnerability results because the Exchange 2000 System Attendant incorrectly adds the "Everyone group" to the security permissions of the HKEY_LOCAL_MACHINE \SYSTEM\\CurrentControlSet\Control\SecurePipeServers\winreg in the registry.
What is the Exchange 2000 System Attendant?
The System Attendant is one of the core services in Microsoft Exchange. It performs a variety of functions related to the on-going maintenance and processing of the Exchange system such as the generation of address lists, offline address books and directory lookup facilities. One of the key functions that the System Attendant performs is to manage the configuration settings for Exchange servers within an organization. A system administrator can use the Exchange System Manager Microsoft Management Console Snap-in to view configuration settings and make changes. The System Attendant then propagates those configuration settings to the appropriate Exchange Servers.
What is the Registry?
The Registry is a central repository for configuration information for Windows and Windows Applications. It provides a single location where operating system settings (devices information, boot sequence, network configuration) application settings (tuning information, configuration parameters), and user settings (user preferences, recently used short cuts) can all be stored.
How does the Registry secure the information it stores?
Because the Registry stores information that is critical to the stability and security of the system, it uses a security model to control access to that information. Because the Registry is organized into a logical "tree structure" much like the file system, the security model is similar to that provided by the Windows NT Files System (NTFS). This security model assigns permissions at each branch of the tree and ends at the actual value. Permissions can be assigned based on Windows username or group membership. The permissions govern a user's and/or group's ability to view, add, change, or delete information within the Registry Value. For example, an administrator may have the ability to view, add, change or delete information from the "WinReg" value, but an unprivileged user may have none or some of those abilities.
What is the WinReg value?
One of the management capabilities that the Registry provides is the ability to connect remotely from another Windows-based system. To ensure the security of this feature, this ability has a security mechanism to ensure that only authorized users can successfully connect remotely to a system's registry. This mechanism is handled by the so-called Winreg key. Specifically, this key is found in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurePipeServers\WinReg. The Security permissions on this value define what Users or Groups can successfully connect remotely to the registry. By default, only Administrators have permissions on this value, and hence the ability to connect remotely to a machine's registry. All other users are denied access, and attempts to connect to the machine's registry as a non-administrator user would fail. The WinReg key is talked about in greater detail in Microsoft Knowledge Base article Q153183.
Does the WinReg value control the ability to add, change or delete information in the Registry?
No. The WinReg Value only controls the ability to successfully connect remotely to a machine's Registry. In essence, it only controls whether a user is able to open a specific computer's Registry. The WinReg Value itself doesn't control a user's ability to view, add, change, or delete specific information in the Registry. That is controlled by the individual permissions within the Registry.
What's wrong with how the Exchange 2000 System Attendant handles the WinReg Key?
To successfully manage the configuration settings on Exchange Servers, the System Attendant requires access to the registry so that an Exchange Administrator can use the Exchange System Manager MMC snap in to view configurations settings and make modifications. To allow that access, the System Attendant sets permissions on the Registry so that the Exchange System Manager can successfully connect. However, in making this change, the Exchange 2000 System Attendant incorrectly adds the "Everyone" group to the WinReg key as part of its configuration settings.
How might an attacker exploit this vulnerability?
An attacker would most likely attempt to exploit this vulnerability by attempting to connect to the Registry of the intended target across the network. To succeed, they would have to establish a connection to the machine's Registry via tcp ports 139 or 445. The Remote Registry Service would also need to be running in order for this connection to occur.
Could an attacker exploit this vulnerability on the Internet?
As long as firewalling best practices are followed, an attacker could not exploit this vulnerability from the Internet. Specifically, if SMB and Direct Host ports are blocked at the firewall, there would be no way for an attacker to successfully connect to the Registry across the Internet.
What would this vulnerability enable an attacker to do?
Because the WinReg value only controls the ability to access the Registry remotely, by itself, this vulnerability would only allow an attacker to remotely connect to the Registry, thereby giving the attacker direct access to the Registry. In itself, this vulnerability does not affect an attacker's ability to manipulate the Registry, only to connect to it. However, it is very important to keep in mind that once an attacker has gained access to a machine's Registry, their actions are constrained by only the specific permissions on each key, subkey, and value. This means that if a Registry value had an inappropriately permissive setting, allowing Everyone Write Access, for example, an attacker could use this vulnerability to gain access to exploit that permissive setting. Because a machines specific Registry permissions are a result of software installed, administrator settings, and security policies as propagated by the Security Configuration Manager and Active Directory, the exact scope of an attacker's possible actions varies from machine to machine. Also, while unauthenticated users cannot access a machine by default, because of the disabling of the Guest account discussed above, an Administrator can choose to enable that account, thus expanding the scope of the vulnerability.
What does the patch do?
The patch eliminates the vulnerability by correcting the behavior of the Exchange 2000 System Attendant and preventing it from granting security permissions on the WinReg value to the Everyone Group.
Does the patch remove the Everyone Group from the WinReg value?
Yes. In addition to changing the behavior of the System Attendant to ensure that it does not grant "Everyone" permission on the WinReg value, the patch also removes the "Everyone" group from the WinReg value.
Does the patch make any other changes to the Registry permissions?
No. The patch only removes the "Everyone" group's permissions on the WinReg key. All other Registry permissions remain intact.
So, does this mean the patch restores the WinReg value's permissions to the defaults?
Not necessarily. While the patch does remove the "Everyone" group which the System Attendant incorrectly adds, it makes no other changes. This means that if an administrator had herself made changes to the WinReg value's permissions, this tool would preserve those changes.
Download locations for this patch
Microsoft Exchange Server 2000:
Additional information about this patch
This patch can be installed on systems running Microsoft Exchange 2000 SP2.
Inclusion in future service packs:
The fix for this issue will be included in Microsoft Exchange 2000 SP3.
Reboot needed: Yes
Superseded patches: None.
Verifying patch installation:
- To verify that the patch has been installed on the machine, confirm that the following registry key has been created on the machine: HKEY_LOCAL_MACHINE\Software\Microsoft\Updates\Exchange Server 2000\SP3\Q316056.
- To verify the individual files, use the date/time and version information provided in the following registry key: HKEY_LOCAL_MACHINE \Software\Microsoft\Updates\Exchange Server 2000\SP3\Q316056\filelist
Localized versions of this patch are under development. When completed, they will be available at the locations discussed in "Obtaining other security patches".
Obtaining other security patches:
Patches for other security issues are available from the following locations:
- Security patches are available from the Microsoft Download Center, and can be most easily found by doing a keyword search for "security_patch".
- Patches for consumer platforms are available from the WindowsUpdate web site.
- Microsoft Knowledge Base article Q316056 discusses this issue and will be available approximately 24 hours after the release of this bulletin. Knowledge Base articles can be found on the Microsoft Online Support web site.
- Technical support is available from Microsoft Product Support Services. There is no charge for support calls associated with security patches.
Security Resources: The Microsoft TechNet Security Web Site provides additional information about security in Microsoft products.
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.
- V1.0 (February 07, 2002): Bulletin Created.
- V1.1 (May 09, 2003): Updated download links to Windows Update.
Built at 2014-04-18T13:49:36Z-07:00