4 ms·
To the skeptics here -- the problem is that malware can turn one kind of USB device into another kind of USB device, and that creates a massive attack surface g
by JackC 12y ago
To the skeptics here -- the problem is that malware can turn one kind of USB device into another kind of USB device, and that creates a massive attack surface given the scope of USB.
Check out all the things that a USB device can claim to be.[1] You don't just need your OS to be secure against a malicious storage device; you need it to be secure against a malicious keyboard and mouse, speaker/microphone/sound card, printer/scanner, CNC machine, webcam, ethernet or wifi adapter, bluetooth adapter, infrared adapter, RNDIS adapter (whatever the heck that is, but it's supported by BSD as well as Windows), an ActiveSync device, a smart card reader, a fingerprint reader ...
As I understand it (and I wouldn't mind being wrong), a hostile USB stick could claim to be a hub running all of these at once, and orchestrate them in an attack. Consumer-oriented OSes will happily load up standard drivers to talk to most of them in an attempt to be user-friendly, each with their own hooks into the OS. And the hostile device can detect what OS and probably specific hardware it's talking to,[2] so it can target an attack at the drivers that are likely to exist.
If that's true, I don't see how anyone could be confident that such a stack could ever be secured on the OS side. A secure bulk storage driver is one thing, but your laptop has to be secure against a hostile keyboard working with a hostile CNC machine, sound card, and ethernet device?
At a minimum it seems like devices should be locked at the hardware level to the kind of device that they are. Code signing makes a lot of sense too, although it's sad to lose the (hypothetical?) ability to install alternative drivers.
[1] http://en.wikipedia.org/wiki/USB#Device_classes http://en.wikipedia.org/wiki/USB#Device_classes
[2] http://ix.cs.uoregon.edu/~butler/pubs/sadfe11.pdf http://ix.cs.uoregon.edu/~butler/pubs/sadfe11.pdf
- eevilspock 12y agoSeems to me that pluggable USB is no different from installable software. So why not just the same sort of sandbox + permissions model that iOS/Android apps live in? Discussed in other thread: https://news.ycombinator.com/item?id=8115002 https://news.ycombinator.com/item?id=8115002
- Burz 12y agoQubes OS is evolving in this direction for all peripheral devices (even some of the ones on the motherboard such as NICs). USB is taking more time, but controllers will in future automatically be sandboxed in Service VMs. For now, a Qubes user can quickly create their own USBVM that uses the system IOMMU (if present) to reassign USB controllers to that VM; Likewise, you can also assign particular USB controllers to individual VMs. These VMs can be selected for autostart at boot time with a couple mouse clicks. A more granular and hence flexible way to sandbox and handle USB devices will be coming to Qubes by way of Xen's PV USB feature. https://qubes-os.org https://qubes-os.org
- PythonicAlpha 12y agoI think, one of the problem here, is the universality aspect of USB. When we had different plugs for different things, no keyboard could pretend to be a mass storage device and vice versa. Now, when you plug something into your USB port, it could be anything. It is similar to the scripting languages, Microsoft included into their office products. Before their where also some scripting possibilities in office products, but most of the time not that powerful. When they did it into the most popular office suite existing, the way for a new kind of virus was paved. The universality of office scripting also made the products more vulnerable to attacks.