USBGuard - what should we allow or disallow by default?

[arraybolt3]

@desi_fubu

https://thehackernews.com/2025/08/linux-based-lenovo-webcams-flaw-can-be.html

I’m not really concerned about this because:

• You have to compromise the system to overwrite the camera’s firmware and turn it malicious. By the time you’ve compromised the system enough to do that, it’s already “game over”.
• The camera has to present itself as a keyboard device in order to attack the system. If the camera is plugged into the system after boot, USBGuard will see one of two things, depending on how the camera presents itself:
  • Either, it will see a camera and a keyboard together, and will thus reject the camera because it combines a human interface device with some other device.
  • Or, it will see just a keyboard, in which case if the user has any other USB keyboard already attached, it will reject the keyboard. (If the user doesn’t have a USB keyboard already attached, then it’s “game over”, but if the camera is only presenting itself as a keyboard and not as a camera, it would be able to evade even the current highly strict settings.
• If the camera is already plugged into the system at bootup, then it’s “game over”, but again, that would be the case even with the current highly strict settings, and if an attacker is able to compromise a system enough to flash a camera with non-standard firmware, they can probably also control USBGuard and allow the camera to be used so it can be attacked.
  • A counter-argument to this is that USBGuard makes an attacker have to take one more step to attack the camera (maybe - does this exploit work even if the system rejects the camera? It probably doesn’t…), and that one more step may be enough to thwart an attacker that doesn’t know they need to take that step.

@desi_fubu

Same as webcams they can be used to record passwords and text via acoustic keyboard eavesdropping with tools like Keytap2. The best thing if someone was concerned would be to unplug these ribbon cables from their computer or de-solder them if its a newer (landfill device) where everything is soldered in.

I’m not sure how I see how this applies to the threat model USBGuard is intended to help with - Keytap-style attacks require either compromising the user’s computer (in which case, why bother with Keytap, just install a keylogger and be done), or requires the attacker to be able to place their own microphone physically close to the victim (in which case the victim’s computer isn’t the one the microphone is plugged into).

@desi_fubu

Arduinos can indeed be used as MIDI interfaces and are used in hacking peripheral devices

I don’t really understand how that would work but it sounds neat, maybe you can share a link?

@desi_fubu

No brainer here Bluetooth is unsafe

I don’t think it’s quite that cut-and-dried, but I agree in general that individual Bluetooth devices can have questionable security (as is true with wireless devices in general sadly) and I would not rely on them in a high-risk situation. That being said, I personally use a Bluetooth mouse and keyboard with my workstation, but I also don’t have a threat model that includes nearby skilled attackers with radio equipment.

@desi_fubu

I don’t get it considering there’s good amount of people that use them to get around Intel ME. Many people including myself would remove the WiFi card and us an external Ethernet USB Adapter as a mitigation technique.

I’m not referencing the idea of USB Ethernet in general when calling it very high-risk, though I do consider it a risk as I’ll explain in a bit. The main problem with USB Ethernet is the implementation - RNDIS (which is used for most Android USB tethering sadly) reportedly has serious protocol-level vulnerabilities, so bad that the kernel maintainer who is arguably second-in-command to Linux Torvalds has tried to remove support for the protocol from Linux entirely, three times. He hasn’t shared what the vulnerabilities are yet, but I think he probably knows what he’s talking about and wouldn’t try to do this if the protocol wasn’t legitimately unsafe. There are other USB Ethernet protocols besides RNDIS, I don’t have as much of a problem with the protocols there.

RNDIS aside, one could argue that if a device presented itself as something normal and a USB Ethernet device, that could be used to mount an attack against running services on the system. Assuming Kicksecure has no open ports by default (I wouldn’t expect it to, but haven’t actually checked), this probably isn’t much of a concern, but if someone’s running something like CUPS on their machine, LAN access to the machine could be enough to take it over completely, if one security researcher is to be believed. See the link about CUPS vulnerabilities in the original post. A device could present itself as USB Ethernet to gain LAN access to the machine, assuming the machine automatically connected to the “network” presented by the device (I believe NetworkManager does this by default).

I do not deny the very good usability benefits of USB Ethernet, but I think in general it presents a significant attack vector from the standpoint of USB devices mounting attacks against a system. I’d prefer if we documented how users can manually allow USB Ethernet, instead of allowing it in general.

This brings up a potential hardening idea I’ll save for another post, it might be possible to mitigate this risk such that we can allow USB Ethernet by default. (Edit: I filed the post, for those who are interested: NetworkManager: Disable automatic connection to wired networks?

@desi_fubu

Malicious USB ethernet devices exist but the general rule of thumb in this manner is don’t buy online and only buy locally from a trusted vendor (brand). Supply chain attack is a real threat but atleast is wouldn’t be targeted to you specifically unlike buying online.

Keep in mind that one threat vector we have to be ready for is a device that looks like one thing to the user but presents itself as something else to the computer. For instance, a malicious pair of USB headphones may present itself to the computer as a USB Ethernet device as well as a USB audio device. Sometimes the malicious device will be one an attacker walks by and plugs in, so the user’s choice of what to buy may not protect them, and the user’s understanding of what they’re plugging into their system may be wrong.