TUCoPS :: Windows Apps :: ciacm030.txt

Multiple Remote Windows XP/ME/98 Universal Plug and Play Vulnerabilities

Privacy and Legal Notice

[CIAC] INFORMATION BULLETIN

M-030: Multiple Remote Windows XP/ME/98 Universal Plug and Play
Vulnerabilities

[Microsoft Security Bulletin MS01-059]

December 21, 2001 19:00 GMT
  ------------------------------------------------------------------------
 PROBLEM:           Microsoft's implementation of the UPNP (Universal Plug
                    and Play) protocol can result in an attacker gaining
                    remote system level access to any default installation
                    of Windows XP.
 PLATFORM:          Microsoft Windows XP (All default systems)
                    Microsoft Windows 98 (Certain configurations)
                    Microsoft Windows 98SE (Certain configurations)
                    Microsoft Windows ME (Certain configurations)
 DAMAGE:            An attacker can gain remote system level access to any
                    default installation of Windows XP. The attacker could
                    also execute a Denial of Service (DoS) and a
                    Distributed Denial of Service (DDoS) attack against
                    vulnerable systems.
 SOLUTION:          Apply the patch as directed in Microsoft bulletin
                    MS01-059.
  ------------------------------------------------------------------------
 VULNERABILITY      The risk is HIGH. An outsider can gain system level
 ASSESSMENT:        access to any Windows XP system that has been
                    installed with default settings.
  ------------------------------------------------------------------------

 LINKS:
   CIAC    http://www.ciac.org/ciac/bulletins/m-030.shtml
 BULLETIN:
   ORIGINALhttp://www.microsoft.com/technet/security/bulletin/MS01-059.asp?frame=true
 BULLETIN:
  ------------------------------------------------------------------------

[***** Start Microsoft Security Bulletin MS01-059 *****]

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.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.

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.
[***** End Microsoft Security Bulletin MS01-059 *****]

  ------------------------------------------------------------------------
CIAC wishes to acknowledge the contributions of Microsoft Corporation for
the information contained in this bulletin.
  ------------------------------------------------------------------------
CIAC services are available to DOE, DOE Contractors, and the NIH. CIAC can
be contacted at:

    Voice:          +1 925-422-8193 (7 x 24)
    FAX:            +1 925-423-8002
    STU-III:        +1 925-423-2604
    E-mail:          ciac@llnl.gov
    World Wide Web:  http://www.ciac.org/
                     http://ciac.llnl.gov
                     (same machine -- either one will work)
    Anonymous FTP:   ftp.ciac.org
                     ciac.llnl.gov
                     (same machine -- either one will work)

  ------------------------------------------------------------------------
This document was prepared as an account of work sponsored by an agency of
the United States Government. Neither the United States Government nor the
University of California nor any of their employees, makes any warranty,
express or implied, or assumes any legal liability or responsibility for
the accuracy, completeness, or usefulness of any information, apparatus,
product, or process disclosed, or represents that its use would not
infringe privately owned rights. Reference herein to any specific
commercial products, process, or service by trade name, trademark,
manufacturer, or otherwise, does not necessarily constitute or imply its
endorsement, recommendation or favoring by the United States Government or
the University of California. The views and opinions of authors expressed
herein do not necessarily state or reflect those of the United States
Government or the University of California, and shall not be used for
advertising or product endorsement purposes.
  ------------------------------------------------------------------------
UCRL-MI-119788
[Privacy and Legal Notice]

TUCoPS is optimized to look best in Firefox® on a widescreen monitor (1440x900 or better).
Site design & layout copyright © 1986-2024 AOH