Microsoft Security Bulletin MS00-047

Technical description:

The NetBIOS Name Server (NBNS) protocol, part of the NetBIOS over TCP/IP (NBT) family of protocols, is implemented in Windows systems as the Windows Internet Name Service (WINS). By design, NBNS allows network peers to assist in managing name conflicts. Also by design, it is an unauthenticated protocol and therefore subject to spoofing. A malicious user could misuse the Name Conflict and Name Release mechanisms to cause another machine to conclude that its name was in conflict. Depending on the scenario, the machine would as a result either be unable to register a name on the network, or would relinquish a name it already had registered. The result in either case would be the same - the machine would not respond requests sent to the conflicted name anymore.

If normal security practices have been followed, and port 137 UDP has been blocked at the firewall, external attacks would not be possible. A patch is available that changes the behavior of Windows systems in order to give administrators additional flexibility in managing their networks. The patch allows administrators to configure a machine to only accept a name conflict datagram in direct response to a name registration attempt, and to configure machines to reject all name release datagrams. This will reduce but not eliminate the threat of spoofing. Customers needing additional protection may wish to consider using IPSec in Windows 2000 to authenticate all sessions on ports 137-139.

What's this bulletin about?
Microsoft Security Bulletin MS00-047 announces the availability of a patch that improves the ability of an administrator to protect against denial of service attacks against Microsoft® Windows NT® 4.0 and Windows® 2000 systems. 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. It results because of shortcomings in an industry-standard protocol used in the affected systems. If a malicious user sent a particular message to a Windows NT or Windows 2000 system, it would cause the machine to relinquish the name by which it's known on the network. This would prevent other machines on the network from being able to request services from it.
The vulnerability does not result from a product flaw in any of the affected systems. It is simply an outcome of the nature of the industry-standard protocol being used here. The patch adds new functionality that makes it more difficult for a malicious user to mount such an attack.

What causes the vulnerability?
This vulnerability results because the NetBIOS over TCP/IP (NBT) protocols specified in RFCs 1001 and 1002 are unauthenticated and allow machines on a network to help manage their peers. The protocols are correctly implemented in Windows NT 4.0 and Windows 2000, but, by design, they are vulnerable to misuse and spoofing. This could allow any machine on a network to spoof a WINS server and send a name conflict or name release datagram to another machine, thereby causing the machine to abandon its name and be unresponsive to requests for service.

What is NetBIOS, and what is NBT?
NetBIOS is a set of networking services for PC networking. NetBIOS can be implemented atop a number of different networking protocols, and there needs to be a standard that describes how the services will be implemented for each case. NBT is the protocol that describes how NetBIOS services are provided on a TCP/IP network.
This vulnerability involves one of the NBT services, namely, the NetBIOS Name Service (NBNS). NBNS is analogous to DNS in the TCP/IP world; it provides a way to find a machine's IP address given its NetBIOS name, or vice versa. In Windows systems, NBNS is implemented as the Windows Internet Name Service (WINS).

What's wrong with how NBT and WINS are implemented in Windows?
Nothing. They are both implemented correctly per the protocol. The vulnerability here results because of deficiencies in the protocol itself. These deficiencies are one reason why support for NetBIOS will be phased out in future versions of Windows.

What's the problem with the protocol?
In any name service, a provision has to be made for cases in which there are name conflicts - that is, two machines that have the same name. The vulnerability exists because the mechanism for identifying name conflicts can be misused. In particular, the Name Conflict and Name Release mechanisms can be misused.

What's the Name Conflict mechanism?
In NBNS, both the name server and NetBIOS clients check for name conflicts. The name server checks for name conflicts whenever a machine registers or refreshes its name, or whenever the server receives replicated data from another name server. A NetBIOS client checks for name conflicts whenever it sends a request to a machine and receives more than one response. In either case, the machine that found the conflict sends a name conflict datagram to the offending machine, which then refuses to answer to that name any longer.
How could the Name Conflict mechanism be misused? A malicious user could send a name conflict datagram to a machine whose name is not in conflict, solely as a means of making it relinquish its name and become unavailable for service requests. For example, if a malicious user sent such a datagram to a machine named \\FILESRV1, it would no longer answer to the name, and other machines would no longer be able to request services from it.
Note, however, that machines can register under multiple name, and these aliases would not be affected by the spurious name conflict datagram. For example, if \\FILESRV1 also had registered as \\PRTSRV1, it would continue to respond to the name \\PRTSRV1 even if had received a false name conflict report regarding \\FILESRV1.

What's the Name Release mechanism?
In NBNS, machines can release their names when they no longer are using them - either by explicitly releasing it or by simply abandoning it. However, NBNS servers also can demand that a machine release its name, as a means of removing name conflicts.

How could the Name Release mechanism be misused?
A malicious user could send a name release datagram to a machine in order to make it relinquish its name. As in the case of the unsolicited name conflict datagram above, this would cause the machine to be unavailable for service requests.

Who could exploit this vulnerability?
If a firewall were in place blocking port 137 UDP (the port over which NBNS name registration traffic occurs), external users could not exploit this vulnerability. Standard security procedures recommend blocking all NetBIOS ports - 137, 138 and 139 TCP/UDP at the external Router and Firewall.

Could this vulnerability be exploited accidentally?
No. The malicious user would need to send a very specific datagram to a specific host. This could not happen accidentally.

If this is just how the protocol works, why are you providing a patch?
Microsoft can't unilaterally change the protocol, but we can provide administrators with the flexibility to restrict which machines can put other machines into a name conflict state. That's the purpose behind the patch.

What does the patch do?
The patch does two things:

• It causes a Windows NT 4.0 or Windows 2000 machine to ignore obviously-spoofed name conflict datagrams. If a name conflict datagram didn't come from the WINS server that the machine registered with, or if it's clearly not a response to a name registration request, the machine will ignore the datagram.
• It provides functionality for Windows NT 4.0 machines that already exists in Windows 2000. This functionality enables an administrator to configure a machine to ignore name release datagrams.

It's worth noting, however, that this patch only makes it harder - not impossible - to spoof the name conflict process. Any protocol that does not include authentication in its messages can be spoofed, and NetBIOS is no exception. Customers who need 100% protection against spoofing attacks may wish to consider using IPSec in Windows 2000 to establish authenticated sessions. For instance, an IPSec policy that authenticates all sessions over ports 137-139 would prevent spoofing attacks via NetBIOS.

After applying the patch, how do I configure a machine to ignore spoofed Name Conflict datagrams?
The new functionality regarding name conflict datagrams isn't toggleable. Once the patch is installed, the restrictions on name conflict datagrams are in force.

After applying the patch, how do I configure a machine to ignore name release datagrams?
Just set the following registry value:

This function is already present in Windows 2000, and the patch adds it for Windows NT 4.0 systems. More information on the function is available in Security Considerations for Network Attacks and Microsoft Windows 2000 Implementation Details.

Who should apply the patch?
Microsoft recommends that this patch only be applied to machines which play a central role in the network and those machines the administrator judges could be a target for such an attack.

Are there any cases in which I should not apply the patch?
Yes. Microsoft always recommends that customers consider the specific risk that a vulnerability poses and weigh it against the benefits of applying a patch. However, it's especially important in this case. The patch removes by-design behavior, and could prevent name conflicts from being resolved. There are cases in innocently-occurring name conflicts could cause greater disruption to a network than a denial of service attack by a malicious network user.
For example, WINS servers normally check for name conflicts when performing replication. Under the protocol, if a name conflict were detected, the WINS server would send a Name Release demand to one of the machines claiming the name. However, if the NoNameReleaseOnDemand setting has been enabled on the machine that received the Name Release demand, it would refuse to relinquish the name and the name conflict wouldn't be resolved.

How do I use the patch?
Knowledge Base article Q269239 contains detailed instructions for applying the patch.

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

How can I tell if I installed the patch correctly?
The Knowledge Base article Q269239 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.

NetBIOS is provided as part of all Windows systems. Why hasn't a patch been provided for Windows 95 and 98?
These systems do implement NetBIOS, but we have not developed a patch for them. The reason is because there is an incompatibility between the effect of the patch and the role in which Windows 95 and 98 machines are most appropriately used.
As discussed above, the vulnerability results from the misuse of normal, by-design management functions provided in NetBIOS. The patch removes some of these functions. It's not appropriate to apply the patch globally - for instance, on all workstations within a large network - because it would impede the ability of the network to cope with normally-occurring name conflicts. Indeed, it's likely that if the patch were deployed globally within a large network, the loss of the normal management functions would cause as much, if not more, disruption than a malicious attack. As a result, we have recommended that the patch be applied only to security-critical machines, and have only developed patches for products that are appropriate in such a role.

What is Microsoft doing about this issue?

• Microsoft has developed a procedure 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 Q269239 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 Technical Support can provide assistance with this or any other product support issue.

Download locations for this patch

• Windows 2000:

  http://www.microsoft.com/downloads/details.aspx?FamilyId=7998A1B2-B8F4-4331-9A1A-ABE49286466B&displaylang=en

• Windows NT 4.0 Workstation, Server, and Server, Enterprise Edition:

  http://www.microsoft.com/downloads/details.aspx?FamilyId=2B07CCD4-B629-4D78-8B18-0D7A8D83FB36&displaylang=en

• Windows NT 4.0 Server, Terminal Server Edition:

  http://www.microsoft.com/downloads/details.aspx?FamilyId=DA8AE101-9B05-4D3A-9A37-6ADF4863613E&displaylang=en