Replies

Microsoft Security Bulletin MS01-059

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

Originally posted: December 20, 2001

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 the Universal Plug and Play service is installed and running.
Affected Software:

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

Technical details

Technical description:

The Universal Plug and Play (UPnP) service allows computers to discover and use network-based devices. Windows ME and XP include native UPnP services; Windows 98 and 98SE do not include a native UPnP service, but one 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 service, 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 doesn’t sufficiently limit the steps to which the UPnP service 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.
In the first scenario, the 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.
In the second scenario, 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.
Mitigating factors:
General:

Standard firewalling practices (specifically, blocking ports 1900 and 5000) could be used to protect corporate networks from Internet-based attacks.
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 runs by default, would make it significantly more difficult for an attacker to determine the IP address of an affected machine. This could impede an attacker's ability to attack a machine via unicast messages. However, attacks via multicast or broadcast would still be possible.

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:

Buffer Overun:CAN-2001-0876
Denial of Service:CAN-2001-0877

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 service in 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 Internet Connection Sharing client 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 service 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 only affects the Windows XP UPnP implementation, and could enable an attacker to gain complete control over an affected system.
The second vulnerability affects all UPnP implementations, and 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 UPnP service contains an unchecked buffer that could be overrun via a specially malformed UPnP NOTIFY directive.
What’s wrong with how the Windows XP UPnP service handles NOTIFY directives?
One of the components in Windows XP involved in processing NOTIFY directives contains an unchecked buffer. If the UPnP service 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 service while it was running.
What would this enable an attacker to do?
An attacker who successfully exploited this vulnerability could change the UPnP service to perform any desired task. Because the UPnP service 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 is that multicast and broadcast messages are not routable. (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 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 (ICF) protect against this vulnerability?
ICF would provide some protection against an attack via unicast messages because, to carry out such an attack, the attacker would need to know the IP address of the target system. ICF causes the machine not to respond to port scans and other common methods of obtaining the IP address, so the attacker might be unable to learn the IP address, and hence unable to send a unicast message to it.
However, this would still leave the possibility of an attack via multicast or broadcast. Because the attacker wouldn't need to know a specific IP address in order to carry out such an attack, ICF wouldn't provide any protection against it.
Does the vulnerability affect all systems on which UPnP is available or only Windows XP?
It only affects the Windows XP implementation of UPnP.
What does the patch do?
The patch eliminates the vulnerability by instituting proper buffer handling in the Windows XP UPnP implementation.

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 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’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 service handles device descriptions?
There are two problems. First, the service 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 service 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 Echo service running. Echo is a standard TCP/IP service that simply echoes whatever is sent to it, and it’s not uncommon to find servers with Echo 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 simply echo the request. The UPnP service would interpret this as being part of the device description, and send a request for more of the file, which the Chargen service would echo back to it. This cycle would 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 UPnP 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 strictly 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.
What does the patch do?

The patch changes how the UPnP services in the affected systems handle device descriptions, as follows:
It sets a maximum size on device descriptions, and ensures that the system doesn’t accept any that exceed that size. It also causes the service to validate the information in the device description, and reject any invalid information. This eliminates the first attack scenario.
It institutes checking to confirm that the download location is valid and that the system doesn’t continually try to download device descriptions from it. It also provides the ability for the administrator to regulate which machines the system will attempt to download such information from. Knowledge Base article Q315056 provides more details on this.
The patch also updates netsetup on Windows XP. Once the patch is applied to a Windows XP machine, any Windows 98 machines that are subsequently configured to use ICS from the patched Windows XP machine will not be affected by the vulnerability. (However, any Windows 98 machines that had ICS installed before the Windows XP patch was applied are vulnerable and do require the patch).

Patch availability

Download locations for this patch

Microsoft Windows 98/98SE:
http://www.windowsupdate.com
or
http://www.microsoft.com/Downloads/Release.asp?ReleaseID=34991
Microsoft Windows ME:
http://www.windowsupdate.com
or
http://download.microsoft.com/download/winme/Update/22940/WinMe/EN-US/314757USAM.EXE
Microsoft Windows XP:
http://www.windowsupdate.com
or
http://www.microsoft.com/Downloads/Release.asp?ReleaseID=34951

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
All patches available via WindowsUpdate also are available in a redistributable form from the WindowsUpdate Corporate site.

Other information:

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

Microsoft Knowledge Base article Q315000 discusses 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.