Proposed procedure for using untrusted USB drives

ok, so still have the application VM. We are just making a way to auto-destroy the sys-usb. Sounds good

Of course, I do nor believe all this cancels the firmware attack issues at all, but may be wrong here.

You are not wrong.
If the USB has attacked the controller, that’s it done. All the Qubes usb
shenanigans is no help.
The only way to deal with this is to reserve a controller for untrusted
USB devices. If you have only one controller, don’t use untrusted devices
at all.

2 Likes

Or, you can use all your untrusted devices exclusively inside the disposable sys-usb and never connect them to other AppVMs.

If you only have one controller every device will end up being
untrusted, and should not be shared with other users.
Because the threat is at the firmware level, the use of a disposable
sys-usb is neither here nor there. That addresses a different class of
threats.

2 Likes

Are there any PCIe USB controller cards (and/or laptop USB controller cards) that are known to not have the firmware vulnerable to USB devices?
I believe we are talking about designers leaving the JTAG open.
Alternatively, if we are talking about the USB taking control of the sys-usb qube and rewriting the usb controllers firmware from the computer side, then are there any known USB controllers that use static ROMS and not flash, or entirely ram that must be loaded after boot ( which would not make sense for those trying to USB boot)

1 Like

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

2 Likes

Interesting. I know that Qubes uses USBip for some of the USB forwarding. USBip documentation says:

The device driver for the exported USB device runs on the client machine

which you can read details of here:
https://www.kernel.org/doc/html/latest/usb/usbip_protocol.html

So it sounds like your proposal is already done for most cases. However, I think the drivers for the keyboard and mouse are in sys-usb. (You can check this by running a terminal in your sys-usb and do a lsmod, then compare with lsmod in dom0.) They probably did this to keep those drivers out of dom0 (which seems like a good idea).

Now you still have the USBip driver in sys-usb and I don’t know how big of a target the USBip driver is. Also, it’s only one driver for all your USB devices, so at minimum it has reduced attack surface.

Note that if you have a USB printer, you should be able to load the printer driver in a qube that is seperate from your qube with the documents you want to print with this:

So maybe you want to create new intermediate service qubes and forward the keyboard from sys-usb to sys-keyboard and the mouse from sys-usb to sys-mouse, then do the handoff to dom0? (note: in the future there can be a handoff to sys-gui-gpu instead)

I would suspect that disabling them like that would mean that they wouldn’t get handed off to remote devices anymore, but maybe someone who knows more about how sys-usb does the device forwarding could answer here?

If we could find a PCIe USB card whos firmware either cannot be updated, or gets loaded during the boot sequence (getting loaded during the boot sequence is unlikely because if you used it for a USB keyboard, the keyboard would not work till boot (which would deny you BIOS access)), and if the card was able to be reset when we reset sys-usb, then I think we’d have something.

However, if such products exist, it’s not obvious how to find them as searches don’t turn up much.

1 Like

I agree that once the device is forwarded, it’s driver is run in a client qube. However there is a substantial period of time before users forward the device (or after they disconnect it) that the device driver is running in sys-usb qube. That can be clearly seen by running lsusb command in sys-usb qube. This exposure will be removed by disabling USB interfaces. And no, it doesn’t prevent USB devices from being forwarded.

On the second thought, I wonder if USB device drivers run in sys-usb qube on my computer simply because it is configured with USB keyboard. Is it the same for computers with PS2 keyboards? Can someone test it?

I’m not concerned much about keyboard USB drivers, because if the keyboard is malicious, it’s game over. They might as well run in sys-usb qube.

With respect to finding a USB controller (or any other hardware) confirming to Joanna Rutkowska’s vision of stateless laptop, they will sure solve a lot of security problems, but I’m skeptical we going to get them soon.

The usb-qube recognizing the USB device enough to list it with lsusb is one thing. It probably needs to identify what the device is before it forwards it. Does the driver automatically load when you plug something in? you can check that with lsmod

A thought occurs. If the usb device happens to be a storage device that sys-usb probably loads a driver for it, as sys-usb allows it to pass through a partition which would imply sys-usb would need some kind of code to be able to handle that.

With disposable sys-usb the impact is limited to a single session.

If you have your keyboard & mouse in dom0 on a dedicated controller (assuming you trust them sufficiently), impact is limited to compromise of one USB device by another during that session.

And yes, parsing block devices requires a driver in sys-usb.

Btw usbguard might interest you.

Does anybody have any idea on how to audit or dump micro-controller firmware. Probably JTAG only stuff, but have no idea. Probably it is more complex than this, but… Anybody?
I think this is what is missing for the most paranoid.

Regards

1 Like

If interfaces are deauthorized (as above) then the driver is NOT loaded. We will not be able to see partitions in this case, and must forward the whole device to another qube for parsing. I used lsusb -t to see which drivers are bound to which devices.

Disposable sys-usb would not prevent attack on USB conroller firmware, and of little help to people with one USB and no PS2 controller (e.g. myself).

I have looked at usbguard. Thank you for the reference. I think udev has similar capabilities. Regardless, implementing security through whitelisting is a lot of work with no guarantee of result. I personally prefer security by isolation approach.

1 Like

Sounds like your saying you tried this. Please confirm: You have tried the procedure you are proposing and checked that the deauthorized USB devices are actually able to get forwarded to other qubes and those other qubes are able to use them (when loading a driver)?

Yes. I’m actively using this procedure all the time. I confirm that on my installation of Qubes (4.0.4) deauthorized USB interfaces (not devices - do not deauthorize devices!) are able to get forwarded to other qubes using standard GUI procedure, that once forwarded, the driver is loaded in those other qubes automatically without any additional user action, and that those other qubes are able to use the USB devices.

I’m still undecided whether there are actual security advantages of this one or whether this is security circus.

For multiple reasons:

  1. IIRC Qubes OS uses usbip over qrexec for USB device attachments. This is a pure software implementation and much different from PCI device attachments which use VT-d. This means that
    a) you are affected by usbip exploits.
    b) not necessarily all devices work with it.
    c) the usbip backend is still handled by sys-usb. Most likely this will include some driver code.
  2. Your instructions need to be executed really early in the VM boot process to avoid race conditions with e.g. USB devices that are plugged in at boot time. That’s why I still consider [usbguard] way superior (there are maintainers who take care of all these details) and way more powerful (your use case is a very simple “block all” [usbguard] policy). Btw it uses the same kernel interface.
  3. For various USB devices (e.g. block devices) it is actually a good idea to keep all driver code in sys-usb to prevent attacks by untrusted USB devices on the destination VM. The aforementioned threat model doesn’t include such much more likely threats though.
  4. The threat model is focused on protecting USB devices attached to sys-usb against each other. If sys-usb is compromised though, it can easily disable all protections of the devices against each other.

In total I believe that if you’re really concerned about one USB device attacking another, use multiple USB VMs and attach each of your USB hubs to dedicated disposable USB VMs and then only use one device per hub/VM per session. There’s full VT-d protection in place then.

[usbguard] https://usbguard.github.io/

I have tried to re-read the discussion several times, but I find that it is a bit heavy topic,
so I would like to re-explain, please kindly review whether there are incorrect understanding.

Several things involved in the discussion:

  • USB controller (Hardware)
  • USB memory stick / thumb drive device (Hardware)
  • USB external hard disk device (Hardware)
  • USB keyboard / mouse / printer device (Hardware)
  • USB controller firmware (firmware)
  • USB controller driver (software)
  • USB keyboard / mouse / printer driver (software)

USB memory stick / thumb drive device - no device driver / using USB controller driver.
USB external hard disk device - no device driver / using USB controller driver.

USB controller driver:

  • first, it is located at dom0,
  • after sys-usb creation, now it is located at sys-usb,
  • without running the “de-authorization script” , then attach USB memory stick / thumb drive device, to laptop then from sys-usb to appVM, USB controller driver at sys-usb will be used.
  • with running the “de-authorization script” in sys-usb, then attach the USB memory stick / thumb drive device, to laptop then from sys-usb to appVM, USB controller driver at appVM will be used.

USB keyboard / mouse / printer driver:

  • first, it is located in the USB keyboard / mouse / printer device,
  • without running the “de-authorization script” in sys-usb , then attach the USB keyboard / mouse / printer device, to laptop then from sys-usb to appVM, USB keyboard / mouse / printer driver will be installed and running in sys-usb.
  • with running the “de-authorization script” in sys-usb, then attach the USB keyboard / mouse / printer device, to laptop then from sys-usb to appVM, USB keyboard / mouse / printer driver will be forwarded, installed and running in appVM.

Advantage of running the de-authoriation script in sys-usb:

  • USB controller driver and USB keyboard / mouse / printer driver, will be forwarded by sys-usb to appVM, and they will run in appVM.
  • if the USB memory stick / external HD / keyboard / mouse / printer is malicious, then it will infect the USB controller driver in appVM, and it will not affect USB controller firmware, because USB controller and USB controller firmware are not attached to appVM.

Do we have to run the de-authorization script, for each time we start sys-usb, or 1 time only ?
What if we use the disposable sys-usb, do we have to run it every time starting the sys-usb ?

is it possible to create sys-driver ?
so we can secure both sys-usb and appVM.
sys-usb - sys-driver - appVM,
or disp-sys-usb - disp-sys-driver - dispAppVM

So guys, please kindly help me to review, whether there are incorrect understanding.

USB controller driver and USBIP server code always run in sys-usb qube with or without “de-authorization script”. The difference is where and when USB device drivers are run (keyboard, mouse, printer, storage, etc…).

Without “de-authorization script”:

  1. there is a period of time after a device is plugged in and before it is forwarded to another qube that device drivers are run in sys-usb qube.
  2. if one does not have a PS2 keyboard, the USB keyboard is automatically forwarded to DOM0, as soon as it is plugged in (including “rubber ducky”).

With “de-authorization script”:

  1. no device drivers are attached to newly plugged in devices in sys-usb
  2. if one does not have a PS2 keyboard, keyboards and mice are not automatically forwarded to DOM0 (prevents “rubber ducky” attack).

About “sys-driver”:

One could create the qube today, but it would probably have very limitted utility. The only use case I can think of is forwarding the whole mass storage device to “sys-driver”, and then forwarding individual partitions from “sys-driver” to appVMs. That would mitigate a hypotethical exploitable bug in partition table parsing code.

1 Like

When to run “de-authorization script”:

  1. after each system reboot
  2. after each sys-usb restart
  3. after system wakes up from sleep

or…

  1. before plugging in any untrusted USB devices

One of course can try to run the script automatically at the above points in time, but if there is no PS2 keyboard, there is a real danger of locking oneself out of the system, since USB keyboards are not automatically forwarded to DOM0 after the script.

1 Like

thanks for the review and correction,

so then, considering these 2 facts:

  • USB controller driver and USBIP server code will always run in sys-usb qube
  • USB controller and USB controller firmware are attached to sys-usb

now, in case there is malicious USB device,
(memory stick, external storage, keyboard, mouse, printer, etc),

  • Without “de-authorization script”, can it infect (direct / indirect):
    USB controller driver, USBIP server code, DOM0, and USB controller firmware ?
  • With “de-authorization script”, can it infect (direct / indirect):
    USB controller driver, USBIP server code, and USB controller firmware ?