Today the SEC Consult Vulnerability Lab released an advisory regarding a vulnerability in a software component called NetUSB. This post intends to give some background information about this vulnerability. NetUSB is a proprietary technology developed by the Taiwanese company KCodes, intended to provide “USB over IP” functionality. USB devices (e.g. printers, external hard drives, flash drives) plugged into a Linux-based embedded system (e.g. a router, an access point or a dedicated “USB over IP” box) are made available via the network using a Linux kernel driver that launches a server (TCP port 20005). The client side is implemented in software that is available for Windows and OS X. It connects to the server and simulates the devices that are plugged into […]

Today the SEC Consult Vulnerability Lab released an advisory regarding a vulnerability in a software component called NetUSB. This post intends to give some background information about this vulnerability.



NetUSB is a proprietary technology developed by the Taiwanese company KCodes, intended to provide “USB over IP” functionality. USB devices (e.g. printers, external hard drives, flash drives) plugged into a Linux-based embedded system (e.g. a router, an access point or a dedicated “USB over IP” box) are made available via the network using a Linux kernel driver that launches a server (TCP port 20005). The client side is implemented in software that is available for Windows and OS X. It connects to the server and simulates the devices that are plugged into the embedded system locally. The user experience is like that of a USB device physically plugged into a client system. It’s worth noting, that the NetUSB feature was enabled on all devices that we checked and the server was still running even when no USB devices were plugged in!

We initially found the NetUSB kernel driver on a TP-LINK device and decided to spend some time on it. To establish a server-connection, a simple mutual authentication check needs to be passed. The authentication is entirely useless as the AES keys are static and can be found in the kernel driver as well as in the client software for Windows and OS X. As part of the connection initiation, the client sends his computer name. This is where it gets interesting: The client can specify the length of the computer name. By specifying a name longer than 64 characters, the stack buffer overflows when the computer name is received from the socket. Easy as a pie, the ‘90s are calling and want their vulns back, stack buffer overflow. All the server code runs in kernel mode, so this is a “rare” remote kernel stack buffer overflow.

It turns out, that not only TP-LINK uses NetUSB in their products. We found references to 26 vendors in the file “NetUSB.inf”, which is part of the client driver setup for Windows. It is likely, that these vendors have licensed the NetUSB technology and are using it in some of their products. Our advisory contains a list of affected devices, where SEC Consult has verified the vulnerability within the firmware. Unless otherwise stated, the list is incomplete regarding other affected vendors.

To get an idea how many products are affected, we downloaded a bunch of firmware images from D-Link, NETGEAR, TP-LINK, Trendnet and ZyXEL (actually, we downloaded all of them). Then we checked if those firmware images contain the NetUSB kernel driver (NetUSB.ko). We found 92 products out of the analysed firmware images that contain the NetUSB code. A list of affected products can be found in our advisory. We did not check the firmware of the remaining 21 vendors. Many affected products are high-end devices and were released very recently (yes, even the ones that look like spaceships!).

Each vendor uses different terminology when referring to the NetUSB feature. NETGEAR calls it ReadySHARE, other vendors simply call it “print sharing” or “USB share port”. Here are a few examples: