Microsoft Security Bulletin MS02-016

                                                                         Print

  Q318593: Opening Group Policy Files for Exclusive Read
  Blocks Policy Application

  Originally posted: April 04, 2002

  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

  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:

        Windows 2000

                      Internet Servers: Low
                      Intranet Servers: Moderate
                      Client Systems: 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

Microsoft Windows 2000 Server and Advanced Server:
http://www.microsoft.com/Downloads/Release.asp?ReleaseID=3684
4

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

  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: 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\Window
s 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\Window
s 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 All patches available via
WindowsUpdate also are available in a redistributable form from the
WindowsUpdate Corporate 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.

_____________________________________________________________________
** TO UNSUBSCRIBE DO NOT REPLY TO THIS MESSAGE!

** SEND ALL COMMANDS TO: LISTSERVLISTSERV.NTSECURITY.NET
** TO UNSUBSCRIBE, send the command "unsubscribe win2ksecadvice"
** FOR A WEEKLY DIGEST, send the command "set win2ksecadvice DIGEST"

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]