Microsoft Security Bulletin MS00-062

Technical description:

This vulnerability could allow a malicious user to corrupt parts of a Windows 2000 system's local security policy, with the effect of disrupting domain membership and trust relationship information. If a workstation or member server were attacked via this vulnerability, it would effectively remove the machine from the domain; if a domain controller were attacked, it could no longer process domain logon requests. Recovering from such an attack would likely require that a known-working configuration be restored from backup.

It would not be necessary to be an authenticated domain member in order to mount an attack via this vulnerability. Any user who could establish a RPC connection with an affected machine and send the proper command sequence to it could exploit the vulnerability. If the malicious user were an intranet user, he could likely attack any machine within the network; if the malicious user were on the Internet, he could likely attack only machines on the network edge that allow RPC connections.

The vulnerability was discovered by an internal security team at Microsoft, and, to the best of our knowledge, it is not known "in the wild". Nevertheless, because of the serious consequences of the vulnerability, Microsoft encourages all Windows 2000 users to either apply the patch or Windows 2000 Service Pack 1 immediately.

What's this bulletin about?
Microsoft Security Bulletin MS00-062 announces the availability of a patch that eliminates a vulnerability in Microsoft® Windows 2000. Microsoft is committed to protecting customers' information,and is providing the bulletin to inform customers of the vulnerability and what they can do about it.

What's the scope of the vulnerability?
This is a denial of service vulnerability. Using the vulnerability, a malicious user could potentially corrupt information on an affected machine, with the effect of preventing the machine from participating in a network. If the vulnerability were exploited against the domain controllers in a network, it could disrupt all network operations.
Recovering from such an attack would be difficult, and likely would require that a working configuration be restored from a backup tape. Under some conditions, the vulnerability could allow a malicious user on the Internet to attack a machine on the network edge (that is, one directly connected to the Internet), but a properly-configured firewall would prevent attacks against machines on the network interior. A malicious user on an intranet, though, would be able to attack virtually any machine on the network.
There is no capability via this vulnerability to usurp administrative control of a machine. The vulnerability was discovered by one of Microsoft's internal security teams, and, to the best of our knowledge, the vulnerability is not "in the wild". It is already eliminated in Windows 2000 Service Pack 1, and customers who have applied the service pack do not need to take any additional action.

What causes the vulnerability?
Through a complicated series of steps, it would be possible for a malicious user to corrupt parts of the local security policy on a Windows 2000 system.

What's a local security policy?
Every Windows system has a local security policy. It's a set of information that encapsulates all aspects of security on the local machine. It defines the users and groups on a machine, specifies the rights and permissions they have on it, determines what machines are treated as trusted, what domain the machine belongs to, and so forth.

What's wrong with the local security policy mechanism?
By design, unprivileged users should not be able to cause any changes in the local security policy on a machine. However, the vulnerability provides a way for a normal user to corrupt parts of it, in order to prevent it from participating in normal network operations.

What would this enable the malicious user to do?
Let's start with what it would not enable him to do. It would not enable him to gain administrative control over the machine or domain. That is, even though the local security policy includes information such as group membership and privileges on the machine, the vulnerability does not provides a way for the malicious user to change this information to arbitrary values.
The scope of the vulnerability is limited to denial of service attacks. By corrupting the local security policy, it would be possible to prevent the machine from functioning as part of the network. That is, the machine would be unable to levy or respond to requests for network services.

When you say "the machine would be unable to levy or respond to requests for network services," what do you mean?
By corrupting the security policy, the malicious user could prevent the machine from being recognized as a member of a domain. Some examples of operations that could no longer be performed include logging onto the domain, requesting files from a file server, or sharing files with other machines.
If the affected machine were a domain controller, the effect would be more severe. If the security policy on a domain controller were corrupted, it would be unable to authenticate login requests to the domain. If all of the domain controllers in a domain were attacked via this vulnerability, it would effectively deny service to the entire domain.

How could an affected machine be put back into service?
In most cases, the only way to restore a machine to service would by restoring a known-working configuration from a backup tape.

Who could mount such an attack?
The primary prerequisite is that the malicious user would need the ability to request services from the target machine via RPC (Remote Procedure Call).

What's RPC?
RPC (Remote Procedure Call) is a communication mechanism that allows processes on one machine to request services from processes on another machine. In order to exploit this vulnerability, the malicious user would need the ability to levy certain requests on the target machine via RPC.

What determines whether someone can levy requests on a machine via RPC?
There are three critical factors:

• Whether RPC is enabled on the target machine.
• Whether the target machine can receive RPC requests - that is, whether there's a means by which the malicious user could convey an RPC request to it.
• Whether the person making the request is authorized to use the service he requested.

Is RPC typically enabled on Windows 2000 machines?
Yes. Any machine that provides a network service would need to have RPC enabled. As a result, it wouldn't be feasible to protect, for example, domain controllers by disabling RPC. However, in cases where a machine does not provide any network services - for instance, a workstation or terminal server - the administrator could protect the machines by disabling the RPC Listener service.

What determines whether a machine can receive RPC requests from another machine?
The primary factor is whether the requester has the ability to deliver data to ports 137, 138, 139 and 443 UDP. A properly-configured firewall will block these ports and protect an affected machine from an Internet-based attack. Within a network, though, it's likely that any machine would be capable to making a request via these ports.
RPC calls also can be made via other networking protocols such as IPX and NetBEUI. However, neither of these protocols are typically supported on the Internet, and this would tend to reinforce this vulnerability's status as primarily an intranet-based one.

Who would be authorized to make the RPC calls needed to exploit the vulnerability?
The RPC services needed to exploit the vulnerability don't require any special privileges - they can be requested by any user on a network.

How serious is this vulnerability?
Microsoft recommends that customers take all security vulnerabilities seriously. However, this vulnerability should be taken especially seriously. It could allow a user to significantly disrupt network operations, and restoring an affected machine to normal service would be a time-consuming process. It is therefore extremely important that all Windows 2000 users either apply the patch or Windows 2000 Service Pack 1 immediately.

Have any customers been actually affected by this vulnerability?
To the best of our knowledge, no customers have been affected by this vulnerability. The vulnerability was discovered by an internal security team at Microsoft, and we have no evidence to suggest that it is an "in the wild" vulnerability.

Does this vulnerability affect Windows NT 4.0?
No. Only Windows 2000 is affected by the vulnerability.

I have Windows 2000 workstations but my domain controllers are running Windows NT 4.0. Am I at risk? 
The Windows 2000 workstations would be at risk, but the domain at large would not be in any danger.

I have Windows NT 4.0 workstations but my domain controllers are running Windows 2000. Am I at risk? 
The Windows NT 4.0 workstations would not be at risk, but they could still be used as platforms for launching a successful attack against the domain controller.

I'm running Windows 2000, and am potentially vulnerable to this issue. What should I do? 
The best course of action is to apply Windows 2000 Service Pack 1. In addition to correcting this problem, it will also will eliminate others that have been previously reported. Customers who cannot deploy Windows 2000 Service Pack 1 should apply the patch

If the vulnerability is eliminated in Service Pack 1, why are you releasing a patch? 
Because of the seriousness of the vulnerability, our goal has been to make a fix available to the broadest possible range of customers. We know that there will be some customers who cannot apply Windows 2000 SP1 yet, and have provided the patch to assist these customers.

Why didn't you release the bulletin the day Windows 2000 SP1 was available? 
When initially released, Windows 2000 SP1 was available only in English. We wanted to protect as many customers as possible, so we released the bulletin when localized versions of both the patch and SP1 were available.

Where can I get the patch?
The download location for the patch is provided in the "Patch Availability" section of the security bulletin .

How do I use the patch?
The Knowledge Base article contains detailed instructions for applying the patch to your site.

How can I tell if I installed the patch correctly?
The Knowledge Base provides a manifest of the files in the patch package.The easiest way to verify that you've installed the patch correctly is to verify that these files are present on your computer, and have the same sizes and creation dates as shown in the KB article

What is Microsoft doing about this issue?

• Microsoft has delivered a patch that eliminates the vulnerability.
• Microsoft has provided a security bulletin and this FAQ to provide customers with a detailed understanding of the vulnerability and the procedure to eliminate it.
• Microsoft has sent copies of the security bulletin to all subscribers to the Microsoft Product Security Notification Service, a free e-mail service that customers can use to stay up to date with Microsoft security bulletins.
• Microsoft has issued a Knowledge Base article explaining the vulnerability and procedure in more detail.

Where can I learn more about best practices for security?
The Microsoft TechNet Security web site is the best to place to get information about Microsoft security.

How do I get technical support on this issue?
Microsoft Product Support Services can provide assistance with this or any other product support issue.

Download locations for this patch

• http://www.microsoft.com/downloads/details.aspx?FamilyId=D1D6BB56-C4B2-4A9F-A82E-4305F7C22627&displaylang=en