This is sort of like working in a lab with toxic chemicals. There is a way to work and wear certain special clothes so you don't get contaminated. Likewise, I wonder if when dealing with malware you can still use the source/infected machines for their functionality, even though they are infected, and still not get infected on the target device when connecting via USB.

I'm wondering because I don't yet know how to think about the directional flow of code in terms of what device can install something on what other devices it can connect to. I'm not sure what pieces there are to take into account. So it seems that if you knew that A would infect anything it's plugged into, but that B wouldn't let any traffic out except a specific acceptable kind, then you could plug A into B, B would get infected but still allow connection to C without C getting infected. That sort of thing.


USB is inherently insecure, as generally speaking devices automatically trust a USB device that is physically plugged in to them. Add to this the fact that many USB devices have the ability to automatically install code from a hidden partition, something originally intended to make the installation of dirvers for the USB device simple and automatic. Because of these two factors, anywhere that has a large number of random USB devices in frequent use is often rife with USB-borne viruses (think University Libraries and similar).

The only 100% safe way to use a USB device is with one of those "USB condoms", a small dongle that prevents any data transfer, allowing only charging. Of course this makes them into charging ports rather than data transfer ports.

  • 1
    Those are driver bugs and are unrelated to the USB protocol or USB devices (with the exception of one, which is a slab-out-of-bounds). Those bugs would exist even if a different interface were used (e.g. if the driver was ported to RS-232 or something). Regardless, citing kernel bugs as an "ability that USB devices have to install code" is incorrect. It would be better to say that USB drivers and class drives may have bugs that could be exploited by malicious USB devices. As such, you cannot call USB "inherently insecure". – forest Jan 3 at 2:40
  • 1
    Inherently insecure implies that the specifications, not the implication, allows for malicious functionality. The reality is that implementations may be insecure, but the specification most certainly is not. – forest Jan 3 at 3:28
  • 2
    Yes I have. While the specification absolutely makes it easier to perform malicious actions, it does not have the ability to automatically install code. Yes, it can be abused (on systems with PnP) to act as a HID device automatically. Yes, the confidentiality is poor as it is half-duplex broadcast bus (for 2.0 and older). Yes, it is easy to social engineer people. But that does not mean that it is capable of executing arbitrary code, short of exploiting an implementation (and not specification) weakness. And in terms of the hub and hardware itself, the protocol is actually really secure. – forest Jan 3 at 3:44
  • 2
    I actually wrote about this in another answer, where I describe the four primary types of attacks that a malicious USB device can perform. None of them allow for arbitrary code execution without exploiting an insecure driver or other implementation problem. – forest Jan 3 at 3:48
  • 1
    @EmilyGray-Fow "USB is inherently insecure" -- you haven't provided any support for this statement. Can you connect some dots? Or explain your logic? – schroeder Jan 3 at 8:20

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.