• Article

Security Bulletin

Microsoft Security Bulletin MS01-059 - Critical

Unchecked Buffer in Universal Plug and Play can Lead to System Compromise

Published: December 20, 2001 | Updated: May 09, 2003

Version: 1.3

Originally posted: December 20, 2001
Updated: May 09, 2003

Summary

Who should read this bulletin:
Customers using Microsoft® Windows® ME or XP, or who have installed the Windows XP Internet Connection Sharing client on Windows 98 or 98SE.

Impact of vulnerability:
Run code of attacker's choice.

Maximum Severity Rating:
Critical

Recommendation:
Microsoft strongly urges all Windows XP customers to apply the patch immediately. Customers using Windows 98, 98SE or ME should apply the patch if Universal Plug and Play support is installed and running.

Affected Software:

  • Microsoft Windows 98
  • Microsoft Windows 98SE
  • Microsoft Windows ME
  • Microsoft Windows XP

General Information

Technical details

Technical description:

Universal Plug and Play (UPnP) allows computers to discover and use network-based devices. Windows ME and XP include native UPnP support; Windows 98 and 98SE do not include native UPnP support, but it can be installed via the Internet Connection Sharing client that ships with Windows XP. This bulletin discusses two vulnerabilities affecting these UPnP implementations. Although the vulnerabilities are unrelated, both involve how UPnP-capable computers handle the discovery of new devices on the network.

The first vulnerability is a buffer overrun vulnerability. There is an unchecked buffer in one of the components that handle NOTIFY directives - messages that advertise the availability of UPnP-capable devices on the network. By sending a specially malformed NOTIFY directive, it would be possible for an attacker to cause code to run in the context of the UPnP subsystem, which runs with System privileges on Windows XP. (On Windows 98 and Windows ME, all code executes as part of the operating system). This would enable the attacker to gain complete control over the system.

The second vulnerability results because the UPnP implementations don't sufficiently limit the steps to which they will go to obtain information on using a newly discovered device. Within the NOTIFY directive that a new UPnP device sends is information telling interested computers where to obtain its device description, which lists the services the device offers and instructions for using them. By design, the device description may reside on a third-party server rather than on the device itself. However, the UPnP implementations don't adequately regulate how it performs this operation, and this gives rise to two different denial of service scenarios:

  • An attacker could send a NOTIFY directive to a UPnP-capable computer, specifying that the device description should be downloaded from a particular port on a particular server. If the server was configured to simply echo the download requests back to the UPnP service (e.g., by having the echo service running on the port that the computer was directed to), the computer could be made to enter an endless download cycle that could consume some or all of the system's availability. An attacker could craft and send this directive to a victim's machine directly, by using the machine's IP address. Or, he could send this same directive to a broadcast and multicast domain and attack all affected machines within earshot, consuming some or all of those systems' availability.
  • An attacker could specify a third-party server as the host for the device description in the NOTIFY directive. If enough machines responded to the directive, it could have the effect of flooding the third-party server with bogus requests, in a distributed denial of service attack. As with the first scenario, an attacker could either send the directives to the victim directly, or to a broadcast or multicast domain.

System administrators should be aware that the patch introduces new functionality that enables them to tailor how patched systems undertake device discovery. As discussed in Microsoft Knowledge Base article Q315056, the patch introduces the ability to configure the UPnP service to download device descriptions only from the local subnet, the subnet or private network, the private network only, or from any IP address. By default, patched systems will only check the subnet or private network for device descriptions.

Customers who cannot install the patch can protect their systems by disabling UPnP support, as discussed in the FAQ.

Mitigating factors:

General:

  • Corporate networks could be protected against Internet-based attacks by following standard firewalling practices (specifically, blocking ports 1900 and 5000).
  • Home networks that use Internet Connection Sharing would be protected against Internet-based attacks, because the Internet Gateway would not forward the packets. Only the gateway machine would be at risk.

Windows 98 and 98SE:

  • There is no native UPnP support for these systems. Windows 98 and 98SE systems would only be affected if the Internet Connection Sharing Client from Windows XP had been installed on the system.
  • Windows 98 and 98SE machines that have installed the Internet Connection Sharing client from a Windows XP system that has already applied this patch are not vulnerable.

Windows ME:

  • Windows ME provides native UPnP support, but it is neither installed nor running by default. (However, some OEMs do configure pre-built systems with the service installed and running).

Windows XP:

  • Internet Connection Firewall, which is turned on by default whenever a networking connection to the Internet is configured via one of the system wizards, would protect against attacks using unicast messages. This would make attacks possible only via broadcast or multicast, which would typically require the attacker to be located on the same network segment as the vulnerable system.

Severity Rating:

Buffer Overrun:

Internet Servers Intranet Servers Client Systems
Windows 98, 98SE None None Moderate
Windows ME None None Moderate
Windows XP None None Critical

Denial of Service Vulnerability:

Internet Servers Intranet Servers Client Systems
Windows 98, 98SE None None Moderate
Windows ME None None Moderate
Windows XP None None Moderate

Aggregate severity of all vulnerabilities eliminated by patch:

Internet Servers Intranet Servers Client Systems
Windows 98, 98SE None None Moderate
Windows ME None None Moderate
Windows XP None None Critical

The above assessment is based on the types of systems affected by the vulnerability, their typical deployment patterns, and the effect that exploiting the vulnerability would have on them. The criticality for Windows XP is rated higher than for Windows 98, 98SE and ME, because only Windows XP is vulnerable in its default condition.

Vulnerability identifier:

Tested Versions:

Microsoft tested Windows ME, Windows NT 4.0, Windows 2000 and Windows XP, and the UPnP service that can be installed on Windows 98 and 98SE, to assess whether they are affected by these vulnerabilities. Previous versions are no longer supported and may or may not be affected by this vulnerability

Frequently asked questions

What vulnerabilities are discussed in this bulletin?
This bulletin discusses two vulnerabilities, both affecting the Universal Plug and Play subsystem in Windows 98, Windows 98SE, Windows ME and Windows XP.

What is Universal Plug and Play?
Universal Plug and Play (UPnP) is a capability that allows devices on a network to discover other devices and determine how to work with them. UPnP is most easily understood by comparison to plug-and-play (PnP) capability that most Windows users already are familiar with. PnP allows the operating system to detect new hardware when you install it on a system. For instance, if you install a new mouse onto your computer, PnP allows Windows to detect it, load the needed drivers, and begin using it. UPnP extends this concept to devices on a network, rather than on the local system itself. UPnP lets computers learn about other devices on the network, and determine how to use them. For instance, a computer could use UPnP to detect whether there are printers on the network that it can use and learn how to use them.

What operating systems support UPnP?

  • Neither Windows 98 nor Windows 98SE include a native UPnP capability. It can only be added by installing the client software for Internet Connection Sharing (ICS) provided in Windows XP.
  • Windows ME includes a native UPnP capability, but it is neither installed nor running by default.
  • Neither Windows NT 4.0 nor Windows 2000 support UPnP.
  • Windows XP includes a native UPnP capability. It is installed and running by default.

Do the vulnerabilities have anything in common other than the fact that they involve UPnP?
Yes. Both involve problems in the way the UPnP subsystem performs device discovery.

What is UPnP device discovery, and how does it work?
Device discovery is the process through which UPnP-capable computers become aware of the availability of devices they can use, and learn how to request services from them. When a UPnP-capable computer boots, there may already be devices on the network that it can use. To determine whether this is the case, the computer sends a broadcast request (called an M-SEARCH directive), asking that any UPnP-capable device within earshot respond directly to it and provide information about using it. Similarly, when a device that supports UPnP (for instance, a UPnP-capable printer) boots, there may already be UPnP-capable computers on the network that would like to use it. The device broadcasts a message (called a NOTIFY directive) to all computers within earshot, announcing its presence on the network and inviting computers to make use of its services.

Suppose a UPnP-capable computer learns that a particular device is available. How does it learn how to use it?
The computer checks to see whether any applications have registered an interest in the type of device that it's learned of. If one has, the computer consults the information sent by the device, which will contain an URL from which the device description - the list of services offered by the device and instructions on how to request them - can be downloaded. The computer then downloads the device description and can begin using the device.

What are the vulnerabilities affecting the UPnP service?
There are two vulnerabilities:

  • The first vulnerability could enable an attacker to gain complete control over an affected system.
  • The second vulnerability could enable an attacker to either prevent an affected system from providing useful service or utilize multiple users' systems in a distributed denial of service attack against a single target.

What's the scope of the first vulnerability?
This a buffer overrun vulnerability. An attacker who successfully exploited this vulnerability could gain complete control over an affected system. Clearly, this is a serious vulnerability, and we strongly encourage customers to immediately apply the patch.

What causes the vulnerability?
The vulnerability results because one of the components of the Windows XP, Windows ME, Windows 98, and Windows 98SE UPnP implementations contains an unchecked buffer that could be overrun via a specially malformed UPnP NOTIFY directive.

What's wrong with how the UPnP subsystem handles NOTIFY directives?
One of the components in these implementations involved in processing NOTIFY directives contains an unchecked buffer. If the UPnP subsystem received a NOTIFY directive that's malformed in a particular way, the effect would be to overrun the buffer with data from the NOTIFY directive. If this data were carefully chosen, it would have the effect of altering the operation of the UPnP subsystem while it was running.

What would this enable an attacker to do?
An attacker who successfully exploited this vulnerability could change the UPnP subsystem to perform any desired task. Because the UPnP subsystem runs as part of the operating system, this would give the attacker complete control over the system.

How might an attacker exploit the vulnerability?
An attacker could exploit the vulnerability by crafting a NOTIFY directive with the needed malformation and sending it to other computers on the network.

How would the attacker send the NOTIFY directive to the other computers?
A NOTIFY directive can be sent either as a unicast message (i.e., one that's sent directly to a specific computer) or as a multicast or broadcast (i.e., one that's broadcast to a group of computers). The specific type chosen by the attacker would be important. The unicast form would enable the attacker greater reach, but at the cost of needing to know more information about the target. In contrast, the multicast form would enable the attacker to compromise multiple machines without knowing much about them, but at the cost of limiting the scope of the attack to computers on the same network segment as the attacker.

How would an attack via a unicast NOTIFY message work?
In the unicast scenario, the attacker would send a NOTIFY message directly to another computer, as though in reply to an M-SEARCH directive from the computer. The advantage of using a unicast message is that the attacker would be able to attack any machine he could deliver the NOTIFY message to. An attacker could potentially compromise machines over great distances by using unicast messages. The disadvantage is that the attacker would need to know the IP address of the target. Most networks use Dynamic Host Configuration Protocol (DHCP) to manage their pool of IP addresses and, as a result, a particular machine's IP address may change fairly frequently. While it's certainly possible to learn a machine's IP address, it could require substantial work depending on the circumstances.

How would an attack via a multicast or broadcast NOTIFY message work?
In the multicast or broadcast scenarios, the attacker would send a NOTIFY message to a multicast or broadcast address, as though from a new UPnP-capable device. The advantage of using these messages is that the attacker wouldn't need to know the IP address of any other machine, and could potentially compromise a large number of machines with a single attack. The disadvantage for the attacker is that most routers and firewalls do not forward multicast and broadcast messages. (To understand why, consider what would happen if they did forward them - every multicast or broadcast from any computer in the world would be delivered to every other computer in the world, and the Internet would quickly become swamped with data). As a result, attacks via multicast or broadcast would generally only be effective within the attacker's network segment, or subnet.

Does this mean that the vulnerability isn't serious?
On the contrary, it's very serious. There can be hundreds of computers on a subnet, and this vulnerability would enable an attacker to gain complete control over all of them with a single NOTIFY directive. We strongly urge customers to immediately apply the patch.

Would a corporate firewall protect against attacks from the Internet?
Yes. Most corporate firewalls block both multicast messages and unsolicited unicast messages. In addition, blocking ports 1900 and 5000 helps to protect against Internet based attacks.

Would Internet Connection Firewall protect Windows XP machines against this vulnerability?
Internet Connection Firewall (ICF) blocks unsolicited unicast messages, so it would protect a Windows XP system against an attack mounted using unicast. This wouldn't provide total protection - ICF doesn't block multicast or broadcast - but it would significantly reduce the risk to Windows XP users. As we discussed above, unicast messages can be sent over great distances, where multicast and broadcast typically cannot. This means that, for Windows XP users, the attacker would likely need to be located on the same network segment in order to exploit the vulnerability.

Is ICF enabled by default in Windows XP?
In general, ICF is automatically enabled anytime a wizard is used to create a networking connection to the Internet. For instance, ICF is turned on in all of the following scenarios:

  • When a Windows XP system is used an Internet Connection Sharing host.
  • When a connection to the Internet is created via the New Connection Wizard.
  • When a connection to the Internet is identified in the Network Setup Wizard.
  • When an Internet connection is created or identified in the Welcome to Windows wizard.

ICF is not enabled by default in cases like the following:

  • If the user chooses to manually create a networking connection. In such a case, all networking options - including ICF - must be enabled or disabled manually.
  • If the connection doesn't directly connect to the Internet - for instance, if it's a connection to a LAN. In such cases, there is generally already a firewall protecting the entire network.
  • If the system was upgraded from a previous version of Windows and already had an existing connection to the Internet. In this case, ICF can be enabled manually.

For more information on the operation of ICF and the conditions under which it's enabled by default, please refer to "Internet Connection Firewall Feature Overview".

I have a home network that uses Internet Connection Sharing to connect to the Internet. Could someone on the Internet attack the machines on the interior of my network?
No. The Internet Connection Sharing gateway would not forward the NOTIFY messages, regardless of whether they're sent by unicast, multicast or broadcast. This means that an Internet-based attacker could not exploit the vulnerability against systems on the interior of the network. He could, though, exploit the vulnerability against the gateway system.

How can I tell if I need the patch?
For Windows XP, 98 and 98SE, it's fairly easy to tell whether you need the patch:

  • If you're running Windows XP, you need the patch. All Windows XP systems are vulnerable in their default configurations.
  • If you're using Windows 98 or Windows 98SE, you only need the patch if you've installed the client software for Internet Connection Sharing.

For Windows ME, it's a little more difficult. Windows ME does contain a UPnP subsystem, but by default it is not running. However, some hardware manufacturers do turn it on in their pre-configured systems. To determine whether the UPnP subsystem is running, follow these steps:

  1. Click Start, Settings, then select Control Panel.
  2. Select Add/Remove Programs.
  3. Select the tab titled Windows Set-up.
  4. In the Components field, select Communications, then Details.
  5. Scroll down and see whether the box to the left of Universal Plug and Play is checked. If it is, you need the patch; if it's not, you don't.

What does the patch do?
The patch eliminates the vulnerability by instituting proper buffer handling in the Windows XP, Windows ME, Windows 98 and Windows 98SE UPnP implementations.

If I can't install the patch, is there any other way to protect my system?
Yes. You can protect your system by disabling the UPnP capability. However, before doing so, you should understand that this will effect how certain system functions operate. Most notably, disabling UPnP in Windows XP will affect the operation of Internet Connection Sharing (ICS) feature, which enables multiple Windows machines to share a single connection through a Windows XP system to the Internet. If the UPnP capability is disabled, ICS clients will be unable to automatically detect the Internet gateway, and you will need to configure the gateway information manually on every client system. Here's how to disable the UPnP capability: Windows XP:

  1. Log on using an account that has administrative privileges.
  2. Click Start, then right-click on My Computer and select Manage.
  3. In the left-hand pane, click the "+" next to Services and Applications, then click on Services.
  4. In the right-hand pane, right-click on SSDP Discovery Service and select Properties.
  5. In the pull-down list titled Startup Type, select Disabled.
  6. In the Service Status section of the dialogue, click on Stop.
  7. Click OK to exit the dialogue, then close the Computer Management window.

Windows ME:

  1. Click Start, Settings, then select Control Panel.
  2. Select Add/Remove Programs.
  3. Select the tab titled Windows Set-up.
  4. In the Components field, select Communications, then Details.
  5. Uncheck the box for Universal Plug and Play.
  6. Click OK to exit the dialogue, then close the Windows Set-up dialogue.
  7. Reboot the machine.

Windows 98 or 98SE:

  1. Click Start, Settings, then select Control Panel.
  2. Select Add/Remove Programs.
  3. Select the tab titled Windows Set-up.
  4. In the Components field, select Communications, then Details.
  5. Uncheck the box for Universal Plug and Play.
  6. Click OK to exit the dialogue, then close the Windows Set-up dialogue.
  7. Reboot the machine.

In the Windows XP instructions above, you said to disable the SSDP Discovery service, but I see a service called "UPnP Device Host". Should I disable this service as well?
No. Despite its name, the UPnP Device Host service is not related in any way to this vulnerability, and there is no need to disable it. The UPnP Device Host service enables other services on Windows XP to advertise themselves as though they were UPnP devices, and isn't involved in any way with how a system handles actual UPnP devices.

If I install the patch on a Windows XP system, and then subsequently use that system to install the client software for Internet Connection Sharing on a Windows 98, 98SE or ME system, do I need to apply the patch to it?
There are two ways to install the Internet Connection Sharing (ICS) client, and the answer depends on which method you choose. One way is to create a Network Setup Wizard floppy disk on a Windows XP system, then use the floppy to install the ICS client on a so-called downlevel system (i.e., one running Windows 98, 98SE or ME). If you use this method, and the Windows XP system on which you create the floppy disk already has the patch, you don't need to patch the downlevel system -- the Network Setup Wizard will install a version of ICS that already has the fix. On the other hand, if you create the floppy on a Windows XP system doesn't have the patch, you'll need to patch the downlevel system after installing ICS. (Of course, you should also patch the Windows XP system). The other way to install the ICS client on a downlevel system is by installing it directly from the Windows XP CD. If you use this method, you will need to install the patch on the downlevel system.

I tried to install the patch on my Windows 98 system, but the patch displayed a message saying that it wasn't intended for my version of Windows. What happened? I've double-checked that I did install the Windows 98 version of the patch. The patch for Windows 98 and 98SE will only install if the ICS client is present on the system, since that's the only means by which a UPnP capability can be added to on the system. The message you saw means that the ICS client isn't present on the system, and the patch is therefore not needed.

What's the scope of the second vulnerability?
The second vulnerability is a denial of service attacks vulnerability. It could be used in either of two ways - it could either be used in an attack that would involve only a single machine, and would slow or stop its performance, or it could be used in a distributed denial of service attack, in which the attacker would direct multiple machines to join forces against a different computer and swamp it with data. This vulnerability could not be used to gain any administrative control over the system - its sole use would be to interfere with the legitimate user's efforts to use it.

What causes the vulnerability?
The vulnerability results because the UPnP implementations in Windows 98, Windows 98SE, Windows ME, and Windows XP don't apply enough constraints to the process they follow when downloading a device description for a UPnP-capable device.

What's the process by which computers locate and download device descriptions?
When a UPnP-capable computer receives a NOTIFY directive, it checks to see whether an application has registered an interest in the type of device that sent the NOTIFY. If one has, the computer consults the NOTIFY directive, which contains the machine address and port number from which the device description can be downloaded. The computer then contacts the specified machine and requests the device description from it.

What's wrong with the way the UPnP subsystem handles device descriptions?
There are two problems. First, the subsystem doesn't limit the size of the device descriptions it downloads, nor does it check to see whether the data that's purportedly a device description is actually valid. Second, the subsystem doesn't take proper steps to ensure that the machine it's been directed to is actually a download site for device descriptions.

What would the first problem enable an attacker to do?
The first problem could enable an attacker to send a user's system to a bogus download site solely for the purpose of slowing or stopping the user's system.

How would an attacker carry out such an attack?
There are many variations that could be used, but here's a fairly straightforward scenario that illustrates one possible attack. Suppose the attacker knew of a server that had the Chargen service running. Chargen is a standard TCP/IP service that simply generates a stream of data whenever a system connects to it, and it's not uncommon to find servers with Chargen running. Of course, if there weren't such a server handy, the attacker could set one up. The attacker could send a NOTIFY directive to a user's system, advertising a new UPnP-capable device and directing the system to connect to the Chargen server. The user's system would send a download request to the server, which would generate random data in response to the request. The UPnP service would interpret this as being part of the device description, and allow the download to continue endlessly, consuming processing resources and disk space on the user's system.

Would the attack cause the user's system to come to a complete halt?
The effect of the attack would be highly dependent on the particulars of the scenario, including the relative processing power and availability of the two systems, the network bandwidth between them, and other factors. In the best case, the attack might only slow the system's performance; in the worst case, it might consume virtually all of the resources on the system, preventing any useful work from being done.

How could the user resume normal service?
The user could restore normal service by stopping and restarting the service that controls the handling of device descriptions, the SSDP Discovery Service

What would the second problem enable the attacker to do?
The second problem would enable an attack that is essentially the reverse of the attack described above. Instead of targeting a user's system for the purpose of slowing it down, the second problem could enable the attacker to cause multiple UPnP-capable systems to join forces in a distributed denial of service attack that would consume all the resources in a single, third-party system.

How would this attack work?
As in the case above, there are many ways to effect an attack, but one straightforward attack would involve sending NOTIFY commands to many UPnP-capable computers, directing them all to contact a third-party server for the device description. If enough machines were involved, the sheer volume of download requests could potentially slow the performance of the third party server, or potentially swamp it altogether.

Would either attack enable the attacker to do anything more than deny service to someone?
No. Neither of these attacks would enable the attacker to gain any form of administrative control over the machines, or to compromise data on them. Both could be used only for denial of service attacks.

Could these attacks, like those in the first vulnerability, be initiated via unicast, multicast, and broadcast?
Yes. As in the vulnerability discussed above, the attacks here could be initiated via unicast, multicast or broadcast NOTIFY directives. All of the same pros and cons would apply in this case: an attacker could use unicast messages to gain greater reach, but at the cost of needing to know the IP address of the target machine; or could use multicast or broadcast messages to attack multiple machines without needing to know their IP addresses, at the cost of limiting the attack to machines on the same network segment as the attacker.

How does the patch prevent the first problem?
The patch prevents the first problem by limiting the data that will be accepted as a device description. The patch establishes a maximum size of device descriptions; if a device description exceeds that size, the UPnP subsystem stops the download. It also causes the subsystem to check the data as it's arriving, and stop the download if the data isn't valid for a device description.

How does the patch prevent the second problem?
The patch eliminates the second problem by limiting where the UPnP subsystem will search for device descriptions. The patch causes it to check the location provided within a NOTIFY message for a device description, and to only proceed with the download if that location passes several tests. The UPnP subsystem checks the download location before trying to download a device description. By default, a patched system will only download a device description that's located on a computer in the same subnet or private address range. The subsystem also checks to see how many router hops are required to reach the location, and only proceeds if this number is sufficiently small. By default, a patched system will only download a device description if the machine hosting it is located four or fewer hops away. Both of these settings are configurable, as discussed in Microsoft Knowledge Base article Q315056. In addition, the patch introduces a delay mechanism to ease network usage. Patched systems will download device descriptions at different rates, depending on how far away the download location is. Download locations that are on public network such as the Internet are downloaded more slowly, in order to limit the demands placed on them. Likewise, each time a system encounters errors when downloading a device description, it increases the length of time it waits before retrying.

If I can't install the patch, can I protect against this vulnerability by disabling UPnP support?
Yes. Instructions for disabling UPnP support are provided above.

Patch availability

Download locations for this patch

Additional information about this patch

Installation platforms:

  • The patch for Windows 98 and 98SE can be installed on any Windows 98 or 98SE system on which the Windows XP Internet Connection Sharing client has been installed.
  • The patch for Windows ME can be installed on systems running Windows ME Gold.
  • The patch for Windows XP can be installed on systems running Windows XP Gold.

Inclusion in future service packs:

  • No future service packs are planned for Windows 98, 98SE or ME.
  • The fix for this issue will be included in Windows XP Service Pack 1.

Reboot needed: Yes

Superseded patches: MS01-054

Verifying patch installation:

Windows 98 and 98SE:

  • To verify that the patch has been installed on the machine, select Start, then Run, then run the QFECheck utility. If the patch is installed, "Windows 98 Q314941 Update" will be listed among the installed patches.
  • To verify the individual files, use the file manifest provided in Knowledge Base article Q314941.

Windows ME:

  • To verify that the patch has been installed on the machine, select Start, then Run, then run the QFECheck utility. If the patch is installed, "Windows Millennium Edition Q314757 Update" will be listed among the installed patches.
  • To verify the individual files, use the file manifest provided in Knowledge Base article Q314757.

Windows XP:

  • To verify that the patch has been installed on the machine, confirm that the following registry key has been created on the machine:
    HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Updates\Windows XP\SP1\Q315000.
  • To verify the individual files, use the date/time and version information provided in the following registry key:
    HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Updates\Windows XP\SP1\Q315000\Filelist.

Caveats:

None

Localization:

Localized versions of this patch are under development. When completed, they will be available at the locations discussed in "Obtaining other security patches".

Obtaining other security patches:

Patches for other security issues are available from the following locations:

  • Security patches are available from the Microsoft Download Center, and can be most easily found by doing a keyword search for "security_patch".
  • Patches for consumer platforms are available from the WindowsUpdate web site.

Other information:

Acknowledgments

Microsoft thanks eEye Digital Security (https://www.eeye.com) for reporting this issue to us and working with us to protect customers.

Support:

  • Microsoft Knowledge Base articles Q314757, Q314941, Q315000 and Q315056 discuss this issue and will be available approximately 24 hours after the release of this bulletin. Knowledge Base articles can be found on the Microsoft Online Support web site.
  • Technical support is available from Microsoft Product Support Services. There is no charge for support calls associated with security patches.

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:

  • V1.0 (December 20, 2001): Bulletin Created.
  • V1.1 (December 26, 2001): Additional detail added regarding how the patch eliminates the denial of service scenarios.
  • V1.2 (December 31, 2001): Bulletin updated to provide additional mitigating factors (ICF is effective against unicast attacks, and ICS protects machines on the interior of home networks), and to provide information on disabling UPnP support.
  • V1.3 (May 09, 2003): Updated download links to Windows Update.

Built at 2014-04-18T13:49:36Z-07:00