2008年（27）
分类： LINUX
2008-06-04 21:44:48
Universal Plug and Play (UPnP) saw the light in the late 1990s. Networks were just becoming popular. Several vendors were coming up with solutions to make networks and networked applications easier to manage. One early attempt was Sun's JINI. As a reaction to JINI (or so I was told) Microsoft came with UPnP. The first Microsoft products to ship with UPnP were Windows Millenium Edition and Windows XP. Since then there have been a lot of programs and devices that depend on UPnP (Live Messenger, Playstation, X-Box) and millions of networked devices that have implemented UPnP, such as routers and, increasingly, media players and media servers.
Early versions of the Microsoft UPnP software suffered from a few buffer overflows. Until 2006 these were the most widely known UPnP bugs. In 2006 at the SANE 2006 conference I presented a paper about bugs in other UPnP devices, which are harder to fix and detect. In January 2008 the GNUcitizen hacker group used a flaw in the Adobe Flash plugin for Internet Explorer to reconfigure routers with UPnP (but only some stacks) and turned a (mostly) local attack into a remote attack.
With more UPnP enabled devices on the market, and more people taking desktop security serious (well, to some extent) some of the focus is shifting towards other devices on the network, such as access points, routers and firewalls, although at the moment it seems that right now desktops are still the prime targets. I have the feeling this will change in the future.
The main goal of UPnP is to make adding network devices and networked programs to a network as easy as it is to plug in a piece of hardware into a PC (or even easier, as that is often error prone). The devices and programs find out about the network setup and other networked devices and programs through discovery and advertisements of services and configure themselves accordingly.
The UPnP stack consists of 6 layers, one of which is optional:
By default a UPnP-capable device tries to get an IP address through DHCP. If no IP address can be obtained through DHCP an address is chosen in the special link local address range (169.254.0.0/16).
When a UPnP capable device joins a network and wants to know what UPnP services are available on the network, it sends out a discovery message to the multicast address 239.255.255.250 on port 1900 via the UDP protocol. This message contains a header, similar to a HTTP request. This protocol is sometimes referred to as HTTPU (HTTP over UDP):
M-SEARCH * HTTP/1.1
HOST: 239.255.255.250:1900
MAN: ssdp:discover
MX: 10
ST: ssdp:all
All other UPnP devices or programs are required to respond to this message by sending a similar message back to the device, using a UDP unicast, announcing which UPnP profiles the device or program implements. For every profile it implements one message is sent:
HTTP/1.1 200 OK
CACHE-CONTROL:max-age=1800
EXT:
LOCATION:
SERVER:SpeedTouch 510 4.0.0.9.0 UPnP/1.0 (DG233B00011961)
ST:urn:schemas-upnp-org:service:WANPPPConnection:1
USN:uuid:UPnP-SpeedTouch510::urn:schemas-upnp-org:service:WANPPPConnection:1
The above is a slightly edited response that is sent by an Alcatel/Thomson Speedtouch ADSL modem, which implements the WANPPPConnection profile.
At a regular interval UPnP capable devices or programs have to send a message to announce their services. A notification message is more or less the same as a response message to a discovery, but are sent to the UPnP multicast address 239.255.255.250 on port 1900 via UDP and have the ST header replaced by a similar header called NT.
Every profile offers a description of itself and the services it offers and makes this available via XML. The response message from the discovery phase contains a header called LOCATION (case insensitive), which is a URL where a file in XML format can be downloaded. This file describes the profile that the device or program implements. There is no default value for this header. In fact, in some devices it is set dynamically at boot time. After a reboot it might be different.
The third step in the protocol is "control": a device or program can ask another device or program to perform an action on the client's behalf, using SOAP. SOAP is a protocol that runs over HTTP and uses XML to describe remote procedure calls to a server and return results from those calls. SOAP is mainly used for web based services. For every major programming language libraries are available that can be used to implement SOAP requests and process SOAP responses.
Requesting a service is done by sending a SOAP request to the so called "control URL" of the control point, with the right parameters. The control URL for a specific profile can be found inside the
For sending SOAP requests only the URL inside the controlURL tag is necessary. It depends on the profile which actions can be performed. The URL found at the URL in the SCPDURL tag is the so called "URL for service description". It describes which SOAP methods can be performed for that profile and what the so-called state variables for the profile are. Whether or not this description actually matches the services that are offered is not guaranteed in practice.
In UPnP there is the concept of so called "state variables". These variables are, as the name says, used for keeping some form of state in UPnP devices and programs. A program can subscribe to state changes: when a state variable is changed, the new state is sent to all programs/devices that have subscribed to the event. A program/device can subscribe to the state variables of a service by subscribing to a URL, which can be found in the URL pointed to by LOCATION.
The eventing protocol in UPnP is based on .
The presentation layer in UPnP refers to the human controllable interface, for example, the webinterface on a router.
Actions and state variables can form a so called 'profile'. The UPnP standardization organizations have standardized a few profiles, which are in widespread use. The most used profiles are:
