[NT] Opening Group Policy Files for Exclusive Read Blocks Policy Application
From: support@securiteam.comDate: 04/06/02
- Previous message: support@securiteam.com: "[NEWS] Cisco Products found to Contain zlib Compression Library Vulnerability"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
From: support@securiteam.com To: list@securiteam.com Date: Sat, 6 Apr 2002 11:55:43 +0200 (CEST)
The following security advisory is sent to the securiteam mailing list, and can be found at the SecuriTeam web site: http://www.securiteam.com
- - promotion
When was the last time you checked your server's security?
How about a monthly report?
http://www.AutomatedScanning.com - Know that you're safe.
- - - - - - - - -
Opening Group Policy Files for Exclusive Read Blocks Policy Application
------------------------------------------------------------------------
SUMMARY
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.
DETAILS
Affected Software:
* Microsoft Windows 2000 Server
* Microsoft Windows 2000 Advanced Server
* Microsoft Windows 2000 Datacenter Server
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.
Patch availability:
Download locations for this patch
* Microsoft Windows 2000 Server and Advanced Server:
<http://www.microsoft.com/Downloads/Release.asp?ReleaseID=36844>
http://www.microsoft.com/Downloads/Release.asp?ReleaseID=36844
* Microsoft Windows 2000 Datacenter Server:
Patches for Windows 2000 Datacenter Server are hardware-specific and
available from the original equipment manufacturer.
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.
ADDITIONAL INFORMATION
The information has been provided by
<mailto:0_28630_E51E4D7D-DECD-43AE-9A29-36080E8D4C3C_US@Newsletters.Microsoft.com> Microsoft.
========================================
This bulletin is sent to members of the SecuriTeam mailing list.
To unsubscribe from the list, send mail with an empty subject line and body to: list-unsubscribe@securiteam.com
In order to subscribe to the mailing list, simply forward this email to: list-subscribe@securiteam.com
====================
====================
DISCLAIMER:
The information in this bulletin is provided "AS IS" without warranty of any kind.
In no event shall we be liable for any damages whatsoever including direct, indirect, incidental, consequential, loss of business profits or special damages.
- Previous message: support@securiteam.com: "[NEWS] Cisco Products found to Contain zlib Compression Library Vulnerability"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
