Microsoft Security Bulletin MS02-016

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:

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.

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.

Download locations for this patch

• Microsoft Windows 2000 Server and Advanced Server:

  http://www.microsoft.com/downloads/details.aspx?FamilyID=45be8076-a85c-484e-b586-b4f964b4d7cc&DisplayLang=en

• Microsoft Windows 2000 Datacenter Server:

  Patches for Windows 2000 Datacenter Server are hardware-specific and available from the original equipment manufacturer.