• Article

Security Bulletin

Microsoft Security Bulletin MS02-016 - Moderate

Opening Group Policy Files for Exclusive Read Blocks Policy Application (Q318593)

Published: April 04, 2002 | Updated: May 09, 2003

Version: 1.2

Originally posted: April 04, 2002

Updated: May 09, 2003

Summary

Who should read this bulletin: Network administrators using Microsoft® Windows® 2000 domain controllers.

Impact of vulnerability: Attacker could block application of Group Policy.

Maximum Severity Rating: Moderate

Recommendation: Administrators should consider applying the patch to domain controllers.

Affected Software:

  • Microsoft Windows 2000 Server
  • Microsoft Windows 2000 Advanced Server
  • Microsoft Windows 2000 Datacenter Server

General Information

Technical details

Technical description:

Group Policy in Windows 2000 is implemented by storing data in the Active Directory and the system volume on the domain controller. This storage location is called the Group Policy Object (GPO). When a machine or user logs onto the domain, it reads the GPO and applies the settings it contains. Most of these settings are also refreshed by default every 90 minutes. However, like most operating systems, Windows 2000 provides several types of read access, including exclusive-read, and this could enable an attacker to lock the Group Policy files, thereby allowing a user to prevent Group Policy from being applied for all users affected by the GPO.

An attacker would likely exploit the vulnerability by first logging onto the domain normally, and then opening the Group Policy files with exclusive read access. She could then log onto the network a second time. Because the policy files would be locked, the second logon would occur without Group Policy being applied. The result would be that, although all previous Group Policy settings on the second machine would remain in force, any new policy settings would not be applied. The attacker's second session would take place using what policy settings had most recently been applied.

The effect wouldn't be limited only to the attacker. Any other user who happened to log onto the network while the Group Policy files were locked would also do so without new policy settings being applied. However, users who weren't involved in the attack might be unable to determine that policy had been blocked. Group Policy application is a transparent process, so such a user would likely be unaware that the intended policy settings have not been applied.

Mitigating factors:

  • The vulnerability would enable an attacker to block the application of new Group Policy settings, but any settings that had been applied during previous logons would remain in force.
  • The vulnerability could only be exploited by a user who had a bona fide userid and password on the network.
  • The specific gain for the attacker would depend on the extent to which the administrator had customized Group Policy on the domain.
  • The vulnerability would provide no way for an attacker to change Group Policy, or to gain user group memberships.
  • An administrator could determine the attacker's identity by using the Shared Folders MMC snap-in to view the userid of the person who had the policy files open.

Severity Rating:

Internet Servers Intranet Servers Client Systems
Windows 2000 Low Moderate 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. The vulnerability is rated low for Internet Servers because best practices recommend against allowing Internet-based users to log onto a domain, and moderate for Intranet servers because it could only be exploited by authorized domain users. It is rated as "none" for client systems because, although the vulnerability could be exploited from workstation, the vulnerability itself affects domain controllers.

Vulnerability identifier: CAN-2002-0051

Tested Versions:

Microsoft tested Windows XP, Windows 2000 and Windows NT® 4.0 to assess whether they are affected by this vulnerability. Neither Windows NT 4.0 nor Windows XP are affected by the vulnerability, as Windows NT 4.0 does not support Group Policy and Windows XP is a client-only system. 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 enable an attacker to block the application of Group Policy within a Windows 2000 domain. Group Policy enables the domain administrator to specify settings for groups of computers and users on a network, such as security settings, desktop settings and applications that can be installed. Blocking the policy would allow an attacker to retain older policy settings rather than being subject to any new ones the administrator had instituted. The vulnerability is subject to several limitations:

  • If any Group Policy settings had been applied during previous logons, they would remain in force - only new policies would be blocked.
  • It could only be exploited by a legitimate network user.
  • While an attack was in progress, it would be possible for an administrator to determine the identity of the attacker.
  • It would not enable the attacker to log into any other user accounts, or to gain membership in any other user groups.
  • It does not provide any opportunity for the attacker to change the network's Group Policies, only to temporarily block their application.

What causes the vulnerability?
The vulnerability results because it's possible to lock Group Policy files, thereby preventing other users from reading them. Without the ability to read Group Policy files, new policy settings could not be applied to the machine or to the user's session.

What is Group Policy?
Group Policy is a technology introduced in Windows 2000, that enables network administrators to configure many of the options available to users. Through Group Policy, an administrator can regulate settings that are applied to users and computers throughout the network. For example, an administrator can use Group Policy to regulate security settings, automatically install software on users' systems, customize users' desktops, and so forth.

How is Group Policy implemented?
Group Policy is stored in the form of data structures called Group Policy Objects (GPOs) within the Active Directory. Different types of policy settings are stored as discrete files - for instance, the policy settings that regulate the look and feel of the desktop are stored in one file, while other policy setting information is contained in other files. Whenever a Windows 2000 machine boots, it contacts its domain controller, reads the Group Policy files, and applies the policy settings that apply to machines. Likewise, whenever a user logs onto the network, Windows 2000 contacts a domain controller, reads the Group Policy files, and applies the settings that apply to the user. In addition, Windows 2000 periodically refreshes the policy settings every 90 minutes.

What's wrong with how Group Policy is implemented in Windows 2000?
Windows 2000 provides a number of modes in which files can be opened, including an exclusive-read mode that prevents any other users from reading the file. Group Policy files can be opened in this mode, and if this is done it would prevent any other users or machines from them, thereby preventing them from applying the Group Policy settings.

Is it a flaw to allow users to open files for exclusive read access?
No. Most operating systems provide an exclusive read capability. And, of course, a user can only lock a file if they've been granted read privileges, so the owner of the file is always free to prevent users from locking files. However, in the case of Group Policy files - which must always be readable by all users at all times - that it's inappropriate to provide an exclusive read option.

What could an attacker do via this vulnerability?
An attacker could use the vulnerability to block the application of Group Policy settings on the network. Specifically, the attacker could log onto the network normally, lock one or more files in one or more GPOs and then log on a second time from a different system. The second logon would take place without Group Policy being applied. (Likewise, if any other user or computer happened to log on while the attack was in progress, Group Policy wouldn't be applied to them either).

Does this mean that when the attacker logged on the second time, there would be no Group Policy settings in effect?
It depends. When Windows 2000 applies Group Policy, it changes the settings on the local system, and the changed settings remain in force unless changed again in the future. By locking the Group Policy files, the attacker could prevent any new policies from being applied, but previously applied ones would still be in effect. The practical effect of this is that if the attacker logged on via a system that had had Group Policy applied previously, the old policy settings would remain in effect. On the other hand, if the attacker logged on via a system that had never had Group Policy applied, the default settings would remain in effect.

What additional privileges could an attacker gain by blocking Group Policy?
The effect of blocking Group Policy would depend on whether the administrator had changed any Group Policy settings since the last time the attacker logged on from the machine and, if so, what the specific changes had been.

What about other users who logged onto the network while the files in the GPO were locked? Would Group Policy be blocked in their cases too?
Yes. If the Group Policy files were locked, all users who logged on - not just the attacker - would do so without Group Policy being applied. However, the important point to remember here is that Group Policy is a transparent process. The attacker would know that it hadn't been applied, because she would know that she had locked the files. But other users wouldn't have any indication that Group Policy had been blocked. (There are, however, tools that will show the Resultant Set of Policies and, if used, they would show a user what policies were in force and when they were applied).

Who could exploit the vulnerability?
Only legitimate network users could exploit the vulnerability. That is, the attacker would need to already have a bona fide userid and password for an account in the domain.

If someone exploited the vulnerability, would it be possible to tell?
Yes. The Shared Files snap-in for the Microsoft Management Console would let an administrator tell who was conducting an attack. The snap-in lets administrators determine the identity of a user who has a particular file open; by checking to see who had the policy files open, the administrator could determine who the attacker was.

Would the vulnerability enable the attacker to change Group Policy?
No. The vulnerability provides no opportunity for an attacker to gain write access to the policy files.

Could this vulnerability be exploited by a user on the Internet?
Only if the network administrator had chosen to expose the domain directly to the Internet and allow Internet-based users to log onto it. However, standard best practices strongly recommend against doing this.

Would the vulnerability let the attacker log on as someone else?
No. Blocking Group Policy wouldn't let users log in as anyone else, nor would it change their user accounts' group memberships. So, for instance, the vulnerability would not provide an attacker with a means of logging onto the network as an administrator.

What systems should the patch be applied to?
The patch only needs to be applied to domain controllers.

My domain controllers are running Windows NT 4.0. Do I need the patch?
No. Group Policy was introduced in Windows 2000, and doesn't exist in Windows NT 4.0

I'm running Windows NT 4.0 domain controllers, but my workstations use Windows 2000. Do I need the patch?
No. What matters is the operating system your domain controllers use -- the client system doesn't matter. If your domain controllers are running Windows 2000, you need the patch. If they're running any other operating system, they don't.

Is Windows XP affected by the vulnerability?
No. Windows XP does allow files to be opened for exclusive reading, but keep in mind that this only becomes a problem for the specific case of Group Policy files, which are stored only on domain controllers. Because Windows XP cannot be used as a domain controller, it's not affected by the vulnerability.

How does the patch eliminate the vulnerability?
The patch causes Windows 2000 to monitor read requests to Group Policy files, and to map any requests for exclusive read access to shared read access instead.

Patch availability

Download locations for this patch

Additional information about this patch

Installation platforms:

This patch can be installed on systems running Windows 2000 Service Pack 2.

Inclusion in future service packs:

The fix for this issue will be included in Windows 2000 Service Pack 3.

Reboot needed: Yes

Superseded patches:

This patch supersedes the one provided in Microsoft Security Bulletin MS01-036.

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\Windows 2000\SP3\Q318593.

  • To verify the individual files, use the date/time and version information provided in the following registry key:

    HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Updates\Windows 2000\SP3\Q318593\Filelist.

Caveats:

None

Localization:

Localized versions of this patch are available at the locations discussed in "Patch Availability".

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.

Other information:

Support:

  • Microsoft Knowledge Base article Q318593 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.

Disclaimer:

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.

Revisions:

  • V1.0 (April 04, 2002): Bulletin Created.
  • V1.1 (April 08, 2002): "More Information" section updated to indicate that MS01-036 is superseded by this patch.
  • V1.2 (May 09, 2003): Updated download links to Windows Update.

Built at 2014-04-18T13:49:36Z-07:00