Evaluate Blocking vendor‑specific USB Classes (e.g., FFh) in USBGuard?

[Gerry-Manders]

My ethernet usb adapter shows with-interface ff:ff:00 with-connect-type "hotplug"

Base Class FFh (Vendor Specific)

This base class is defined for vendors to use as they please. These class codes can be used in both Device and Interface Descriptors.

ff:*:* is the vendor‑specific class code (class 0xFF) with a vendor‑specific subclass (0xFF) and protocol 0x00. It is commonly used by USB‑Ethernet chips (e.g., ASIX AX88179, Realtek RTL8153) and other devices that provide their own proprietary protocol over USB.

https://www.asix.com.tw/en/product/USBEthernet/Super-Speed_USB_Ethernet/AX88179A

https://devicehunt.com/view/type/usb/vendor/0B95

https://forum.openwrt.org/t/usb-to-ethernet-adapter-asix-elec-corp-ax88x72a/164968/7

F****** proprietary should I be concerned now or what? Because the class is undefined by the USB‑IF, can it also be abused to hide unexpected functionality?

With so much proprietary today is it only generic adapters that use this? Do you think its commonplace with name brand Ethernet adapters commonly found in box stores to also use vendor-specific aka proprietary?

Also both my mouse and keyboard I bought in person say HID? ( I bought in person not online)

Wired optical mouse (Walmart ONN brand) output: with-interface 03:01:02 with-connect-type "hotplug"

Wired keyboard output: with-interface { 03:01:01 03:00:00 } with-connect-type "hotplug"

The USB Ethernet Adapter I bought on Amazon so...kinda worried here

Does the driver listed with usbcore mean that it can secretly use HID or is that global dependency for the whole USB stack of all active USB devices?

user@host:~$ lsmod | grep ax88179
ax88179_178a           36864  0
usbnet                 57344  1 ax88179_178a
mii                    16384  2 usbnet,ax88179_178a
usbcore               348160  9 xhci_hcd,ehci_pci,usbnet,usbhid,usb_storage,ehci_hcd,xhci_pci,uas,ax88179_178a

Can udev be used to see which kernel driver was selected. Like If a device that should be a plain mouse or ethernet ends up bound to a generic driver that accepts vendor‑specific control transfers would that indicate a red flag?

---

Key points

Security surface

Vendor‑specific class FFh lets a device define its own protocol. An attacker could craft a malicious dongle that pretends to be a harmless peripheral (network card, storage, etc.) while actually executing hidden commands.

Device compatibility

A portion of consumer‑grade USB‑Ethernet adapters (ASIX AX88179, Realtek RTL8153, etc.) use class FFh.
How much that is undetermined and needs more research.

[Gerry-Manders]

On linux can you block certain drivers like proprietary ax88179_178a from having access to certain parts of the USB stack? Like it is vendor‑specific USB class and doesn't show up ass a HID class. Can I block it from using HID in the USB stack without blocking that function of other HID devices like true mouses and keyboards?

As mentioned here https://forums.gentoo.org/viewtopic-t-1175217-start-0.html a Ethernet adapter with the same driver AX88179 is using the cdc_ncm driver via lsusb -t

Here is my lsub output for my adapter and in my case it is Driver=ax88179_178a for context --

user@host:~$ lsusb | grep "AX88179"
Bus 004 Device 002: ID 0b95:1790 ASIX Electronics Corp. AX88179 Gigabit Ethernet
user@host:~$

user@host:~$ lsusb -t | head -4
/:  Bus 04.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/6p, 5000M
    |__ Port 6: Dev 2, If 0, Class=Vendor Specific Class, Driver=ax88179_178a, 5000M
/:  Bus 03.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/14p, 480M
    |__ Port 1: Dev 2, If 0, Class=Human Interface Device, Driver=usbhid, 1.5M
user@host:~$

Can we use udev to block hid binding for known vendor-specific vendor's of network adapters and only authorize the network interface?

Example: RUN+="/bin/sh -c 'echo 0b95 1790 > /sys/bus/usb/drivers/usbhid/unbind'"

https://stackoverflow.com/questions/38786343/prevent-usbhid-from-autoloading-when-usb-hid-device-is-plugged-in

@ArrayBolt3
What I'm getting at if I make sense is can a malicious USB change drivers like switch to Driver=usbhid or a proprietary driver in the case of a vender-specific class hide or have HID capabilities and we wouldn't know it due to the nature of proprietary and proprietary protocols?

Also without shifting the topic away how does this syntax ensure only one legit HID (mouse & keyboard) to be allowed?

Allow only one keyboard & Allow only one mouse to be connected

Is it basically the first (interface 03:01:01) that appears after the daemon starts is accepted and the same for mouse?

[ArrayBolt3]

@Gerry-Manders I'm not an expert at how the various device drivers for USB devices work under the hood, so I can't really give a certain answer here. That being said, it is possible for a single USB hardware device to present itself as two or more "real" USB devices at the same time. It's probably even possible for a USB device to present itself as both a legitimate device, and a hub through which other devices are connected (like a malicious keyboard). So in that sense, a device could theoretically change itself to be a mouse or keyboard (possibly even while retaining its existing functionality) and do bad things.

However, with all that being said:

• Right now USB networking devices aren't actually allowed by default. Anything that isn't explicitly allowed is denied, including the FFh class you mentioned in the title. So you'd have to explicitly allow the USB Ethernet device in this instance.
• If a device was to add a keyboard to itself in some way, it would either:
  • show up as the device having multiple interface descriptors, one of which is a keyboard or mouse; USBGuard is configured to disallow these devices entirely because such a combination is suspicious,
  • Or, it would show up through a hub in some fashion, in which case the virtual keyboard or mouse might be allowed through, but only if you didn't already have a USB keyboard or mouse plugged in. That could be a danger if you're using a laptop where both the keyboard and touchpad are connected via LPC rather than USB.

Maybe it would be worthwhile to disallow keyboards and mice that are plugged in after the system is powered on, in all instances. Users who have non-USB pointing devices can simply click the USBGuard notifications to allow them without a reboot if desired, users who have only USB pointing devices can allow a new keyboard or mouse before unplugging the old one. (And for the unlucky user who unplugs all their USB pointing devices and then discovers they can't plug in a new one, that user will just have to reboot. That's pretty non-ideal though...)