Revised: Microsoft Security Bulletin - MS02-001From: Russ (Russ.Cooper@RC.ON.CA)
- Previous message: Maxim S. Shatskih: "Media Player patch and Windows File Protection problems"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Wed, 24 Apr 2002 15:50:15 -0400 From: Russ <Russ.Cooper@RC.ON.CA> To: NTBUGTRAQ@LISTSERV.NTBUGTRAQ.COM
This bulletin has been revised.
V1.0 (January 30, 2002): Bulletin Created.
V1.1 (April 24, 2002): Bulletin updated to advise availability of Windows NT 4.0 Server, Terminal Server Edition Security Rollup Package.
Original bulletin details follow;
Trusting Domains Do Not Verify Domain Membership of SIDs in Authorization Data
Originally posted: January 30, 2002
Who should read this bulletin: Administrators using Microsoft® Windows NT® 4.0 or Windows® 2000 domain controllers.
Impact of vulnerability: Privilege elevation.
Recommendation: System administrators should review the bulletin below and a technical white paper on the subject, and deploy SID Filtering on domain controllers where appropriate.
- Microsoft Windows NT 4.0
- Microsoft Windows 2000
Trust relationships are created between Windows NT or Windows 2000 domains to allow users in one domain to access resources in other domains without requiring them to authenticate separately to each domain. When a user in a trusted domain requests access to a resource in a trusting domain, the trusted domain supplies authorization data in the form of a list of Security Identifiers (SIDs) that indicate the user's identity and group memberships. The trusting domain uses this data to determine whether to grant the user's request.
A vulnerability exists because the trusting domain does not verify that the trusted domain is actually authoritative for all the SIDs in the authorization data. If one of the SIDs in the list identified a user or security group that is not in the trusted domain, the trusting domain would accept the information and use it for subsequent access control decisions. If an attacker inserted SIDs of his choice into the authorization data at the trusted domain, he could elevate his privileges to those associated with any desired user or group, including the Domain Administrators group for the trusting domain. This would enable the attacker to gain full Domain Administrator access on computers in the trusting domain.
Exploiting this vulnerability would be difficult, and require administrative privileges on the trusted domain, as well as the technical wherewithal to modify low-level operating system functions and data structures.
- Windows NT 4.0 provides no mechanism by which additional SIDs could be added to authorization data. To exploit the vulnerability, an attacker would need to develop and install custom operating system components to add the SIDs.
- Windows 2000 does provide a mechanism for introducing additional SIDs into authorization data, known as SIDHistory. However, there is no programming interface that would allow an attacker - even with administrative rights - to introduce a desired SID into the SIDHistory information; instead, an attacker would need to perform a binary edit of the data structures that hold the SIDHistory information.
Microsoft has developed a mechanism called SID Filtering that eliminates the vulnerability and adds further protection between trusting domains. When installed and enabled on the domain controllers of a trusting domain, SID Filtering causes the system to inspect all incoming authorization data and remove any SIDs that do not identify a user or security group that is defined in the trusted domain.
There are, however, tradeoffs associated with using the SID Filtering mechanism. These are summarized in the FAQ and Caveats sections below, and are discussed in detail in Microsoft Knowledge Base article Q289243 and in a technical white paper that Microsoft strongly urges administrators to read before using SID Filtering. This is especially important in the case of administrators who are in the midst of migrating their networks from Windows NT 4.0 to Windows 2000.
- The attacker would need to have domain administrator privileges in the trusted domain in order to exploit the vulnerability.
- The attacker's domain would need to already be trusted by the target domain, or the target domain's administrator would need to approve the establishment of a new trust relationship. There is no capability for the attacker to unilaterally initiate a trust relationship with another domain or cause it to trust the attacker's domain.
- The attacker would need to modify operating system components and data.
Vulnerability identifier: CAN-2002-0018
This email is sent to NTBugtraq automatically as a service to my subscribers. Since its programmatically created, and since its been a long time since anyone paid actual money for my programming skills, it may or may not look that good...;-]
I can only hope that the information it does contain can be read well enough to serve its purpose.
Russ - Surgeon General of TruSecure Corporation/NTBugtraq Editor