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:

The first is by far the easiest. The second method is not too hard either in the WRT54G, but it is not where you would expect it: in the administrative interface go to Setup and choose the Basic Setup menu (default). Save the configuration, wait a few seconds, and the connection should be back.

The code that implements this functionality can be found in the file wanipc.c in the IGD sources of the Broadcom stack.

© 2006-2019, Armijn Hemel/