Repository navigation
Evaluate Blocking vendor‑specific USB Classes (e.g., FFh) in USBGuard? #342
Description
Activity
@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
FFhclass 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...)
- Right now USB networking devices aren't actually allowed by default. Anything that isn't explicitly allowed is denied, including the
What about implementing a “first device wins” rule for the Vendor Specific class & Wireless Controller class 0xe0 with (subclass 0x02 for Wi‑Fi) that brings the same level of protection that the current keyboard rule provides. By allowing only one instance of each risky class, in this case vendor-specific and wifi interface?
At the very least we could add this line commented out and leave it up to the user if its deemed too "risky", whatcha think?
I don't think this is a good idea. I would expect the drivers for USB networking to be rather complicated (indeed, network hardware drivers are "scary" enough that Qubes OS boxes them into an entire VM of their own,
sys-net, to prevent them from compromising dom0). Right now we wholesale block USB networking devices it appears, and I think that is the safest behavior. Users can allow them with one click thanks to USBGuard's notifier, so this shouldn't have any substantial effect on usability. We should only allow things by default that are very common, or that are impossible to manually permit in some instances (input devices in safe-looking scenarios).The behavior about how drivers (usbhid) are loaded and selected is what I'm confused about. Can a device that is "vendor-specific" class or "WiFi" class load the usbhid driver instead of intended driver?
That's a very good question, and one I don't have the answer to. I'd need to read the kernel source code to figure that out. I would at least expect that shouldn't be possible though, it would be very weird if it was possible.
By the time your udev snippets run, aren't they a bit too late? If the kernel has already loaded the driver for the device, can't it have delivered a payload already?
That's a pretty interesting article. It looks like then it is possible to load the "wrong" driver for a particular device, in which case our existing protections are probably not adequate. Maybe something udev-based like what you're suggesting would be a good idea then, though if it could reject a device before the driver loads that would be best.
Would it be possible to write "none" to this attribute before the kernel attempts to bind a driver, the kernel will skip auto binding for that device entirely. (
/sys/bus/*/devices/*/driver_override)If we were to do that, we'd probably have to take over doing driver probing ourselves somehow (i.e. if a device identifies itself as a USB keyboard, and it passes the interface rules, then block driver probing, allow the device, then try to load just usbhid and if that fails kick the device off). I'm not sure if the kernel allows that, but if it does, it might be interesting to at least try. I suspect that could break some devices though (the quirks that allow a device to identify itself as one thing and then actually be another thing are there for a reason), so ideally there should be some way to allow a user to say "allow this device even though it's trying to act in a deceptive fashion, and allow driver probing for it".
My ethernet usb adapter shows
with-interface ff:ff:00 with-connect-type "hotplug"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?
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
Device compatibility