• Article

Security Bulletin

Microsoft Security Bulletin MS00-036 - Critical

Patch Available for 'ResetBrowser Frame' and 'HostAnnouncement Frame' Vulnerabilities

Published: May 25, 2000

Version: 1.0

Originally posted: May 25, 2000

Summary

Microsoft has released a patch that eliminates two security vulnerabilities, one affecting Microsoft® Windows NT® 4.0 and Windows® 2000, and the other affecting Windows NT 4.0 only. Under certain conditions, the vulnerability could allow a malicious user to make it difficult or impossible for other users to locate services and computers on a network; in the worst case, it could allow him to provide incorrect information about the same services and computers.

Affected Software:

  • Microsoft Windows NT 4.0 Workstation
  • Microsoft Windows NT 4.0 Server
  • Microsoft Windows NT 4.0 Server, Enterprise Edition
  • Microsoft Windows 2000 Professional
  • Microsoft Windows 2000 Server
  • Microsoft Windows 2000 Advanced Server
    NOTE: Windows 95, Windows 98, and Windows NT 4.0 Server, Terminal Server Edition, also provide an implementation of the Computer Browser protocol. However, they are not listed as affected products because the scenario in which these vulnerabilities could be exploited - large networks that rely on computer browsing - are exactly the ones most unlikely to use Windows 95, Windows 98 or Windows NT 4.0 Terminal Servers as master browsers.

Vulnerability Identifiers

General Information

Technical details

Technical description:

Windows NT 4.0 and Windows 2000 implement the CIFS Computer Browser protocol. Two vulnerabilities exist because of the inability of administrators to limit whether Master Browsers respond to certain frames. The two vulnerabilities are:

  • The "ResetBrowser Frame" vulnerability, which affects both Windows NT 4.0 and Windows 2000. Like most implementations, the Windows implementation provides the ability for a Master Browser to shut down other browsers via the ResetBrowser frame. However, there is no capability to configure a browser to ignore ResetBrowser frames. This could allow a malicious user to shut down browsers on his subnet as a denial of service attack against the browser service, or, in the worst case, to shut down all browsers and declare his machine the new Master Browser.
  • The "HostAnnouncement Flooding" vulnerability, which does not affect Windows 2000. Because there is no means of limiting the size of the browse table in Windows NT 4.0, a malicious user could send a huge number of bogus HostAnnouncement frames to a Master Browser. The resulting replication traffic could consume most or all of the network bandwidth and cause other problems in processing the table as well.

If a firewall were in place and blocking port 138 UDP, neither vulnerability could be exploited by an external user. Even an internal user could only attack browsers on the same subnet as his machine. Normal administrative tools would allow the administrator to determine who had mounted the attack.

Frequently asked questions

What's this bulletin about?
Microsoft Security Bulletin MS00-036 announces the availability of a patch that eliminates two vulnerabilities, one affecting Microsoft® Windows NT® 4.0 and Windows® 2000 systems, and the other affecting only Windows NT 4.0 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?
These vulnerabilities could allow a malicious user to make it difficult or impossible for users on a network to locate services or other computers on the network. In the worst case, the first vulnerability also could enable the malicious user to provide bogus information to network users. Under most conditions, the malicious user could only exploit these vulnerabilities within the subnet that his machine is on. Also, if a properly-configured firewall is in place, external users could not exploit this vulnerability against a network. Finally, normal system administration tools would allow the administrator to find the user who mounted the attack.

What are the vulnerabilities?
There are two vulnerabilities at issue here:

  • The "BrowserReset Frame" vulnerability, which affects Windows NT 4.0 and Windows 2000 systems.
  • The "HostAnnouncement Flooding" vulnerability, which affects only Windows NT 4.0 systems.

These two vulnerabilities have no relationship to each other, except for the fact that both involve the Computer Browser service.

Do these vulnerabilities involve Internet Explorer?
No. The type of browsing at issue here is not web browsing, it's computer browsing. Computer browsing is a mechanism for discovering servers within a domain that provide particular services. When you use Network Neighborhood in Windows to find other computers, you're using the computer browsing mechanism. Computer browsing is included in the CIFS/E family of protocols. CIFS is the Common Internet File System, and defines a standard protocol for accessing remote file systems over the Internet. This enables groups of users to work together and share documents across the Internet or within their corporate intranets. CIFS/E is a family of protocols that extend CIFS for use in enterprise networks. Among the protocols in CIFS/E is one that discusses implementing a computer browser.

How does computer browsing work?
Under the protocol, every domain on a subnet has a Master Browser. The function of the Master Browser is to manage the other browsers (called Backup Browsers) and to hold the authoritative list of servers and resources available in the domain. Whenever a new server joins the domain, it registers with the Master Browser and tells it what services it provides. Periodically, the Master Browser replicates its list of servers and resources to the Backup Browsers, which service queries from clients. If the domain spans several subnets, there will be a Domain Master Browser whose job it is to keep the Master Browsers for all of the subnets synchronized. By default, the Primary Domain Controller serves as the Domain Master Browser. However, if something happens to the Domain Master Browser, or any of the other master browsers, an election is held among the remaining browsers to determine which one will be elevated to Master Browser. The browsers communicate with each other by means of commands called frames. The vulnerabilities at issue here involve the functioning of two of these frames, the ResetBrowser frame and the HostAnnouncement frame.

The Computer Browser sounds a lot like the Active Directory in Windows 2000. What's the relationship between them?
The Computer Browser and Active Directory perform similar tasks - both help users find machines and services available on the network. However, the similarity ends there. The Active Directory is significantly more efficient and secure, and customers who are working in a homogeneous Windows 2000 environment don't need the Computer Browser at all. In fact, the Computer Browser is only provided in Windows 2000 for downlevel compatibility, and will be phased out entirely in future versions of Windows.

What causes the "ResetBrowser Frame" vulnerability?
This vulnerability results because the ResetBrowser frame can be misused to shut down a machine that provides browsing information. This could be used to deny browse services to a network, and in some cases could allow a malicious user to usurp the browse service.

What machines are affected by this vulnerability?
The vulnerability affects Windows NT 4.0 and Windows 2000 machines that are used as Domain Master Browsers, Master Browsers, or Backup Master Browsers.

What does the ResetBrowser frame do?
The ResetBrowser frame allows a Master Browser to shut down a Backup Browser. Although not required by the protocol, virtually all implementations of the Browser protocol, including non-Microsoft implementations, include this frame. There are two scenarios in which the ResetBrowser frame is typically used. First, it's used to remove extraneous backup browsers from a subnet. If there are more browsers than needed, the replication traffic could cause the network performance to suffer. Second, if a backup browser is out of sync with the other browsers, the Master Browser may use the ResetBrowser frame to shut it down.

What is the problem with the ResetBrowser frame?
There isn't a problem with the ResetBrowser frame per se. The vulnerability results because there isn't a way to configure machines to ignore the Reset Browser frame, and a malicious user could send a ResetBrowser frame to shut down one or all of the browsers.

If this frame is usually used by Master Browsers, why could the malicious user send it?
By design, the Computer Browser protocol is unauthenticated. In itself, this doesn't constitute a security vulnerability, any more than it does for TCP/IP or other unauthenticated protocols. However, it does mean that administrators should take precautions to minimize the opportunity for malicious users to misuse the protocol's unauthenticated nature. One of the purposes of providing the patch for this issue is to allow administrators to do that.

What would this vulnerability allow a malicious user to do?
If a malicious user significantly winnowed the browser population for a domain, the overall network performance could suffer. However, if he shut down all of the browsers, the rules for electing a new Master Browser would allow the malicious user's machine to simply declare itself the new Master Browser. If the machine happened to be on the same subnet as the Domain Master Browser, it could potentially become the Domain Master Browser through this attack.

If a malicious user exploited this vulnerability, could an administrator tell what had happened?
Yes. The simplest case would be the one in which the attacker reset all of the browsers and declared his machine the new Master. It would be obvious who had mounted the attack, because his machine would be the Master Browser. The more difficult case would be the one in which the malicious user shut down some but not all of the browsers, and didn't attempt to make his machine a Master. The administrator would know when the attacks occurred, because Browser shutdowns are recorded in the event log. He also would know that the attack originated on the same subnet as the attacked machines, because NetBios is a non-routable protocol. He could then determine which machines on the subnet had been active when the attack occurred. If additional data were needed, he could use network monitoring to eventually find the malicious user.

What causes the "HostAnnouncement Flooding" vulnerability?
This vulnerability results because a malicious user could send an extremely large number of HostAnnouncement frames to a Master Browser in order to swell the browse list - the list of servers and services available on the subnet.

What machines are affected by this vulnerability?
Only Windows NT 4.0 machines that are used as Domain Master Browsers, Master Browsers, or Backup Master Browsers could be affected by this vulnerability. Windows 2000 already has functionality to limit how large the browse table can become, and isn't affected by this vulnerability.

What does the HostAnnouncement frame do?
The HostAnnouncement frame is what a server uses to tell a Browser Master what services it provides. When the server initially comes online, it sends a HostAnnouncement frame to add its services to the browse list; if the list of services changes, the server sends another HostAnnouncement frame to update the list.

What is the problem with the HostAnnouncement frame?
There isn't a problem with the HostAnnouncement frame. Servers must have a way to tell the Master Browser what services they provide. The vulnerability results because there is no way for the Master Browser to limit how many entries a malicious user can add to the browse list.

What would this vulnerability allow a malicious user to do?
If a malicious user sent a sufficiently large number of HostAnnouncement frames to the Master Browser, it could have three effects:

  • The Master Browser might not be able to tend to any of its other tasks while it processed the incoming HostAnnouncement frames.
  • When the Master Browser replicated its browse table to the Backup Master Browsers, the resulting network traffic could consume most or all of the available network bandwidth
  • When a client used Network Neighborhood to browse the list of nearby computers, handling the huge browse table could prevent the client from performing any other useful work.

If a malicious user exploited this vulnerability, could an administrator tell what had happened?
Yes. Exploiting this vulnerability would require that the malicious user create and send a huge number of HostAnnouncement frames. As in the case of the "ResetBrowser Frame" vulnerability, a network administrator would know that the frames had originated from a machine on the same subnet as the attacked machine. Network monitoring would allow the administrator to determine who was sending them

Could either of these vulnerabilities be exploited remotely?
If recommended security precautions have been observed, neither vulnerability could not be exploited remotely. If a firewall were in place blocking port 138 UDP, it would prevent ResetBrowser frames or HostAnnouncement frames from reaching the machines on the interior of the network.

What does the patch do?
The patch provides registry entries that will let an administrator configure a machine to ignore ResetBrowser and HostAnnouncement frames. On Windows NT 4.0 machines, two new registry keys are provided:
Hive HKEY_LOCAL_MACHINE \SYSTEM
Key CurrentControlSet\Services\RDR\Parameters
Name RefuseReset
Value Type DWORD
Default Value None (ResetBrowser frames are accepted)
Hive HKEY_LOCAL_MACHINE \SYSTEM
Key CurrentControlSet\Services\MrxSmb\Parameters
Name MaximumBrowseEntries
Value Type DWORD
Default Value 100000

Windows 2000 already supports the MaximumBrowseEntries value, so the Windows 2000 patch only adds support for the RefuseReset value. (Please note that the registry key value for Windows 2000 is different than for the Windows NT 4.0 value discussed above).
Hive HKEY_LOCAL_MACHINE \SYSTEM
Key CurrentControlSet\Services\MrxSmb\Parameters
Name RefuseReset
Value Type DWORD
Default Value None (ResetBrowser frames are accepted)

The functioning of the registry entries is discussed in Knowledge Base articles Q262694 and Q263307, respectively.

Why isn't the RefuseReset registry key enabled by default?
The RefuseReset key is disabled by default because it's not appropriate to set it on every machine, or even on every browser. The benefit of RefuseReset is that it prevents the possibility of a spoofing attack. The disadvantage is that it makes a serer less manageable -- and there are times when a Master Browser needs the ability to shut down a remove a troublesome Backup Browser. In addition, enabling RefuseReset could potentially expose the network to a different type of attack, in which a malicious user would proliferate browsers on the subnet in order to consume network bandwidth. To counter this, administrators may wish to consider disabling the Browser service on machines that are not intended to participate as browsers. In contrast, there is no reason why the MaximumBrowseEntries value should not be set on all machines that are used as browsers. There is rarely, if ever, a need for more than 100000 entries in a browse table.

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

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

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

The computer browser protocol is implemented on all Windows systems. Why isn't there a patch for Windows 95, Windows 98 and Windows NT 4.0 Server, Terminal Server Edition?
These systems do implement the Computer Browser protocol, but we have not developed a patch to add the RefuseReset and MaximumBrowseEntries functions for these systems. The reason is because the networks in which the attack at issue here would pose the greatest risk - large networks with many users - are exactly those most unlikely to use these systems as browsers.

What is Microsoft doing about this issue?

  • Microsoft has developed 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 Knowledge Base articles 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.

Patch availability

Download locations for this patch

Additional information about this patch

Installation platforms: Please see the following references for more information related to this issue.

  • Microsoft Knowledge Base (KB) article Q262694, https:
  • Microsoft Knowledge Base (KB) article Q263307, </https:>https:

Other information:

Acknowledgments

Microsoft thanks the following people for working with us to protect customers:

  • COVERT Labs at McAfee, for reporting the "ResetBrowser Frame" vulnerability to us.
  • David Litchfield of Cerberus Information Security, Ltd, for reporting the "HostAnnouncement Flooding" vulnerability to us.

Support: This is a fully supported patch. Information on contacting Microsoft Product Support Services is available at </https:>https:.

Security Resources: The Microsoft TechNet Security Web Site provides additional information about security in Microsoft products.

Disclaimer:

The information provided in the Microsoft Knowledge Base is provided "as is" without warranty of any kind. Microsoft disclaims all warranties, either express or implied, including the warranties of merchantability and fitness for a particular purpose. In no event shall Microsoft Corporation or its suppliers be liable for any damages whatsoever including direct, indirect, incidental, consequential, loss of business profits or special damages, even if Microsoft Corporation or its suppliers have been advised of the possibility of such damages. Some states do not allow the exclusion or limitation of liability for consequential or incidental damages so the foregoing limitation may not apply.

Revisions:

  • May 25, 2000: Bulletin Created.

Built at 2014-04-18T13:49:36Z-07:00 </https:>