Broadcom UPnP stack
A popular chipset for routers is manufactured by Broadcom. Quite a few manufacturers (Linksys, Asus, US Robotics, NETGEAR, Sitecom, Siemens, ...) have or had devices that are based on a Broadcom chip. The UPnP stack on these machines is often also made by Broadcom. There are various versions of the UPnP stack available on Broadcom chips. It looks like devices based on the BCM63xx chipset (with ADSL) have a stack that uses libiptc and devices without ADSL use a different stack. For the latter sources are usually available in the GPL tarball for the device, even though the sources themselves are not GPL licensed. The focus of the rest of this page is on this version of the Broadcom stack.
Onion routing
One problem with this version of the Broadcom stack is that the NewInternalClient in the AddPortMapping SOAP request is not checked to
see if NewInternalClient actually is a
machine you want to forward to (that is, on your LAN), so you can stick in an
IP address which is not on your LAN. If you do this the iptables code will
happily perform NAT on incoming packets on the external interface of your
router. This effectively turns your router into an onion router.
Not
all Broadcom based devices have this problem. It seems US Robotics found and
fixed this problem already in March 2005, but patches never went upstream to
Broadcom. Many recent Linksys devices also have similar fixes, even though
this is no guarantee.
The code errors can be found in the file
ipt.c in the
function AddPortMapping. If you track back through the
functions you will see that there are no checks to guarantee that the value of
NewInternalClient is a value on the LAN.
The Linksys devices that are not vulnerable to this attack have a function
called compare_subnet which compares the value of NewInternalClient with the devices own internal IP. If they don't
match an error is returned.
Disconnecting the router
One of the methods in the WANIPConnection subprofile is the ForceTermination method. With this method it is possible to
terminate the WAN connection of the router immediately. Its counterpart to
enable it using UPnP is the RequestConnection method. Many stacks don't implement this method
and return an error code if the method is used. The Broadcom stack does
implement this method and it actively terminates the connection on a router.
When it is used it is hard to debug for an end user, because the LEDs don't
change when this method is used and it appears the WAN connection is just
working fine. There are a few possibilities for an unknowing user to restore
the connection:
- powercycle the router
- use the webinterface to restart the connection
The code that implements this functionality can be found in the file wanipc.c in the IGD sources of the Broadcom stack.