Home Routers That Support NetUSB May Have Critical Kernel Vulnerability

Now that the patch has been distributed to vendors, Sentinel One researchers have Announcement details A worrying bug in IoT software drivers called network usb.

This product is from a Taiwanese hardware and software manufacturer named code, which is described as follows:

[A] Leading supplier and developer of USB over IP technology products. Today, KCodes solutions are embedded in more than 20% of the world’s network devices.

The idea is neat: NetUSB is a virtual connector for USB hardware, so you can plug a range of different USB devices directly into your router and access them remotely from some, many, or all other devices on the network.

Instead of sharing USB devices by plugging them (such as disk drives, printers, or TV tuners) into various laptops, desktops, and mobile phones in turn, you can connect USB devices to your router by connecting a virtual hub that permanently connects USB devices to your network .

You then share it out using a “virtual USB cable” that transfers USB data over a wireless network rather than a physical cable – much like how Windows allows you to redirect drive letters, directories, and files over the network NET USE Order.

Kernel drivers open to Internet traffic

Sentinel One researcher Max van Amerongen thinks there may be code worth digging he checked NetGear routers from 2021, found that the kernel driver listens for network connections on TCP port 20005.

It’s worth noting that the driver is listening on the network interface 0.0.0.0, which is shorthand for “all interfaces” and thus covers localhost, the internal LAN, and the WAN interface for external connections.

network interface for localhost Can only be accessed by programs running directly on the router itself – in fact, the “NIC” for this interface is implemented entirely in software, usually obtaining an IP number 127.0.0.1 on an IPv4 network.

Internal LANs usually have a so-called “private” IP number, usually 192.168.x.x or 10.x.x.x, which only works on the LAN itself, so by default the outside world is inaccessible.

But your WAN interface, which is short for WAN Wan, which roughly means “the entire internet”, usually has a public IP number, usually issued automatically by your ISP every time your router starts up.

You should assume that your WAN interface is visible and accessible from anywhere in the world.

In other words, a TCP network service listening explicitly on a WAN port, or implicitly by specifying an all-encompassing IP number 0.0.0.0, is generally exposed to almost anyone, can be probed by anyone, and (if questionable) can be exploited by almost anyone.

To make matters worse, most computers that are listening for connections from the outside world—whether they are accidental or intentional—are discovered and poked automatically, regularly, and repeatedly.

Even if you’re not advertising your visitors publicly, like you run your own web server or blog site, researchers and crooks will find you without actually trying, usually within minutes of your router being up.

An IPv4 network can support approximately 4 billion distinct simultaneous connections and uniquely identifiable devices (this is because a 32-bit network number can take up to 2³² different values, and 2³² = 4,294,967,296)…

…but at contemporary network speeds, even a relatively modest business Internet connection can try every possible IP number—billions! – Hours or even minutes.

In short, someone who wants to find a vulnerable router can and will do so without targeting you specifically because it’s very easy to locate anyone by literally trying everyone.

buffer overflow

It didn’t take long for van Amerongen to find a problem in the code in the Kcodes NetUSB driver that handles incoming network data.

As with many TCP protocols, the first step is to read in and identify the command the user wants to execute.

If you’ve ever used HTTP, you know that incoming commands are specified in the first few bytes of the first network packet, using a human-readable sequence of bytes such as GET, HEAD, POST and OPTIONS.

In NetUSB, commands are specified with numeric codes rather than text strings, van Amerongen found a command numbered 0x805F (32,863), which is specified by a command called SoftwareBus_dispatchNormalEPMsgOut.

(we don’t know what EP message means in this case, but it doesn’t matter because it’s not the command itself that creates the hole, it’s the preparation that handles the command. )

After selecting by number, this function then reads a 32-bit value that represents the size of the message the user wants to send, and allocates enough kernel memory to hold what follows.

Except the code doesn’t work that way, because it actually asks “as much memory as the user requests, plus the extra 17 bytes we’ll use during processing”.

Those extra 17 bytes are what introduces the security hole.

In pseudocode, the driver does the following:

   U32   size = read(socket,4);          // get 32-bit size from network
   void* buff = kernel_alloc(size+17);   // allocate the needed memory, plus 17 additional bytes
   if (buff == NULL) { error(...); }     // make sure there was enough memory
   [... accept data into buff...]

Later, the code reads data from the other end – until, but not necessarily, size bytes worth – then copies all the data it receives into the allocated memory area buff.

You may have discovered the problem.

If the user asks the driver to allocate a lot of RAM by setting size Say, a value of 3 billion (this would fit in 32 bits – see above), kernel_alloc() will almost certainly fail, and the function will fail gracefully.

But if the user asks for almost, but not quite, 2³² bytes of RAM, then the actual requested number will end up, for example, as (0xFFFFFFFF + 17).

Except that only 32 bits can be used, the sum shown above exhibits a “Millennium Bug” problem because (0xFFFFFFFF + 17) = 0x10000010, which is 33 bits long.

So the sum overflows and is “packed” back to 32 bits, which is 0x10 (16), the same way AD1999+1 returns to AD1900 year due to a Y2K error, if you only have two digits to use to represent the year.

In other words, an attacker can ask for 2³²-1 byte of data (0xFFFFFFFF); will erroneously receive a buffer of only 16 bytes; can then send as much data as they want, be it 100 bytes, 1000 bytes, or really, at most Any number of 0xFFFFFFFF bytes…

…but any byte starting at number 17 will cause a buffer overflow.

Sentinel One did not take this attack further, arguing that “it is difficult to write an exploit for this vulnerability”, although van Amerongen wisely points out:

We believe this is not impossible, so users with Wi-Fi routers may need to look for firmware updates for their routers.

what to do?

• If your router provides NetUSB to install devices over the network, check for updates. Note, just check that your router is listening for TCP connections on port 20005 (e.g. using map) by itself is not enough, but it’s a useful hint that you might run into problems if you know how to do a port scan.
• Don’t listen on all network interfaces by default unless you really need to. If you’re writing code to accept and handle incoming network connections, minimize privileges and open connections as few times as possible.
• If you write code that allocates memory based on what an untrusted outsider says, always check for reasonable limits. Even if this buffer overflow is impossible, we can’t imagine why SoftwareBus_dispatchNormalEPMsgOut The function will need to allocate close to 4GB of RAM. (According to Sentinel One, NetGear’s patch is a limitation size to only 16MBytes. )
• Always check for integer overflow and underflow when computing with untrusted input. Overflow is where a positive number becomes too large and wraps around to the beginning of the range, as in this case; underflow is where the number ends up below zero, but effectively wraps around to the end of the range.

Underflow may sound confusing at first, but if you confuse signed and unsigned numbers, underflow usually results in a huge overflow.

You can imagine this by imagining a vintage car’s odometer showing 00001 reversed by 2 kilometers: after the first kilometer it will correctly go back to 00000, but after the second kilometer it will apparently jump forward, reading 99999.

The odometer doesn’t have any way to represent negative values, it puts 00000 and 99999 next to each other in its number loop, so it has its own style of “clock” arithmetic, where 99999 + 2 gives 1, and 1 – 2 gives 99999

---

Read More..