Because I was reading something about on a post down there: (my own notes picked from several websites, including MS KB) *term: Buffer Overrun An attack in which a malicious user exploits an unchecked buffer in a program and overwrites the program code with their own data. If the program code is overwritten with new executable code, the effect is to change the program's operation as dictated by the attacker. If overwritten with other data, the likely effect is to cause the program to crash. *term: Denial of service A condition in which users are deliberately prevented from using network resources. *term: Globally-unique Identifier (GUID) A number that is known to be unique and which is assigned to a session or user in order to identify them. 1. UPnP - Universal Plug n Play Universal Plug and Play (UPnP) allows computers to discover and use network-based devices. Windows ME and XP include native UPnP support. 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. 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: 1 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. 2 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. Corporate networks could be protected against Internet-based attacks by following standard firewalling practices (specifically, blocking ports 1900 and 5000). 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. 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: Log on using an account that has administrative privileges. Click Start, then right-click on My Computer and select Manage. In the left-hand pane, click the “+” next to Services and Applications, then click on Services. In the right-hand pane, right-click on SSDP Discovery Service and select Properties. In the pull-down list titled Startup Type, select Disabled. In the Service Status section of the dialogue, click on Stop. Click OK to exit the dialogue, then close the Computer Management window. 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. There is a great deal of confusion being caused by Microsoft's non-obvious naming of the two UPnP services. This situation is exacerbated by the FBI's NIPC web site, which has unfortunately posted wrong information over the holidays. People are led to believe that disabling the service named "Universal Plug and Play Device Host" disables the UPnP system. But it does not. That service is not even running by default. The correct action is to STOP then DISABLE the service named "SSDP Discovery Service". To disable the Universal Plug & Play system: UnPnP first stops the UPNPDH service if it is running, then disables its future operation. After this is done the SSDPDS service is stopped and also disabled. This shuts down Windows XP's external Internet server to prevent exposure to any presently known or later discovered UPnP vulnerabilities. To re-enable the Universal Plug & Play system: UnPnP simply reverses the process. The SSDPDS service is set to start on demand, and it is then started. Then, the UPNPDH service is also set to start on demand, but it is not started. With the SSDPDS service running the Windows XP system will have TCP port 5000 open and accepting remote connections and UDP port 1900 listening for inbound datagrams. UnPnP's actions are completely benign and reversible. There are no known negative side effects caused by disabling the Universal Plug & Play components when they are not needed. They may easily be re-enabled if they are ever needed at any time in the future. Note: Microsoft has a nasty and very insecure habit of "undoing" non-standard system changes that have been made to enhance the system's security. Mostly after you download new Updates and patches. Note: Client programs like Windows itself, and later versions of Windows Messenger, periodically search the local network for a UPnP router to control. This network noise is annoying, but it does not mean that Windows' UPnP server is still active and insecure. Routers: A non-UPnP aware NAT router makes a terrific hardware firewall since it discards unexpected and unsolicited inbound Internet packets. But as routers become UPnP-aware their behavior will need to be carefully scrutinized with regard to Internet pass-through.