Very interesting topic. I would like to revive it, because I have an idea of how to mitigate the threat to USB controller firmware without any additional hardware. It should even work with a single USB controller, to which a keyboard is attached (exactly my situation). I would like to hear your opinion about this idea.
Threat model:
After reviewing a number of published USB attack vectors, it seems that direct reprogramming of USB controller from a USB device has not been documented, demonstrated, or even suspected. At least I couldn’t find any references. If anyone knows about it, please let me know. Check this out: “Researchers from the Ben-Gurion University of the Negev in Israel have identified 29 ways in which attackers could use USB devices to compromise users’ computers” (https://www.bleepingcomputer.com/news/security/heres-a-list-of-29-different-types-of-usb-attacks/). Note, that none of the 29 attacks involve reprogramming USB controller directly from a USB device. Let’s put that threat aside.
An easier attack vector would be to exploit USB driver volnurability, OS volnurability, or trick the user to gain control over OS, and then use use that control to re-flash the USB controller. This is the attack vector I’m trying to mitigate.
Solution Summary:
sys-usb qube has USB controller attached to it, however sys-usb only binds keyboard/mouse drivers to USB devices (with user permission of course). All other devices are delegated to other disposable qubes, where they are bound to appropriate drivers. If the driver qube is penetrated, it will not be able to access USB controller firmware, because neither USB controller nor any other PCI controller is attached to it. Thus usb drivers are removed from the attack surface. We can now trust sys-usb qube more.
Implementation:
We don’t need to change much in the existing system (maybe some usability improvements). It should be able to handle it as it is right now.
Step 1: run this script from a terminal in sys-usb qube (taken from https://www.kernel.org/doc/Documentation/usb/authorization.txt)
for dev in /sys/bus/usb/devices/usb*
do
echo 0 | sudo tee $dev/interface_authorized_default > /dev/null
done
From now on, any new USB device plugged into the computer will be looked at by the USB host controller driver, interfaces queried, but no device driver will be attached.
Step 2: Start a disposable qube and attach your device there using Qubes OS gui or command line.
The target qube now has full control of the USB device. If it was a memory stick it will automatically be mounted. The sys-usb qube on the other hand still doesn’t have a device driver attached to any of the USB device interfaces, and all the interfaces are still deauthorized.
Result:
All device drivers are moved to other qubes. The attack surface is significantly reduced.
Problem remaining:
USB host controller driver still operates in sys-usb qube, and it’s not without potential problems: https://www.nccgroup.com/globalassets/our-research/uk/whitepapers/usb_driver_vulnerabilities_whitepaper_v2.pdf