Proposed procedure for using untrusted USB drives

This is a proposal for a procedure for using untrusted USB drives. I’m putting it in “user support” cause I’m looking for feedback on it. I am expecting many revisions. If we can get it into a solid working procedure, I’ll move it to “user support - guides”.

The situation:
You need to look at the contents of a USB flash drive that you found in the parking lot, or on your desk or whatever. The point is that we don’t trust the USB flash drive.

the rest of this post is a draft of a proposal

First, the AppVM one time setup procedure:
(do either the “easier version” or the “hardcore version”, not both)
Easier Version:

qvm-create --class AppVM --label gray --template debian-10  sys-usb-flashdrive-template
qvm-prefs sys-usb-flashdrive-template template_for_dispvms true

Hardcore version:

sudo qubes-dom0-update qubes-template-debian-minimal

qvm-create --class AppVM --label gray --template debian-minimal  sys-usb-flashdrive-template
qvm-prefs sys-usb-flashdrive-template template_for_dispvms true
(then apt-get install qubes-usb-proxy inside the debian-minimal template)

Next, the disposable VM one time setup procedure:

qvm-create -C DispVM -l red --template sys-usb-flashdrive-template disp-sys-usb-flashdrive
qvm-prefs disp-sys-usb-flashdrive virt_mode hvm
qvm-service disp-sys-usb-flashdrive meminfo-writer off
qvm-prefs disp-sys-usb-flashdrive autostart true
qvm-prefs disp-sys-usb-flashdrive netvm ''
qvm-prefs disp-sys-usb-flashdrive provides_network false
qvm-pci attach --persistent disp-sys-usb-flashdrive dom0:00_11.0
qvm-pci attach --persistent disp-sys-usb-flashdrive dom0:00_11.2

#qvm-features <sys-VMName> appmenus-dispvm ''

then add “disp-sys-usb-flashdrive $anyvm deny” as the first line of both these files:

/etc/qubes-rpc/policy/qubes.InputMouse
/etc/qubes-rpc/policy/qubes.InputKeyboard

Finally the procedure to use it:

  1. boot Qubes (without the flash drive in the USB socket)
  2. create a separate sys-usb2 for just that USB controller, leaving your other usb devices in a different sys-usb .
  3. set the policy for no keyboard and no mouse in sys-usb2 (probably somewhere in /etc/qubes-rpc/)
  4. start a disposable VM with no networking
  5. insert the USB flash drive into the correct usb socket to connect to sys-usb2 (note that the importance of doing this at this moment and not having the flash drive in at boot)
  6. Once the drive registers with qubes, then using the devices icon at the top, connect the flashdrive to the disposable VM
  7. use the disposable VM to view and interact with the files on the flash drive.
  8. when you are done, remove the flash drive from the USB socket
  9. destroy the disposable VM (by just closing it)
  10. then destroy disp-sys-usb-flashdrive (by shutting it down)

THE PROBLEM THAT IS STILL LEFT:
However since many USB controllers forget to turn off the ability to reprogram the firmware, and if the flash drive can attack the firmware in the usb controller, then can’t the compromised USB controller itself act as a USB device during the next reboot in order to comprise dom0?

In the past I’ve attempted to find a USB controller card that gives some kind of guarantee that it has the ability to reprogram the controller disabled, but did not have luck.

Some references:

You can just make your sys-usb disposable and reboot it after usage with untrusted USB stick? I think it makes things much easier.

1 Like

Great idea. I’ll adjust the instructions

I agree.

You can just make your sys-usb disposable and reboot it after usage with untrusted USB stick? I think it makes things much easier.

I do this as standard, but go a little beyond that: use debian-minimal or fedora-minimal just with the minimal amount of required packages. So no usb mouse or usb keybord possible.
Then make a disposable VM template and then create a disposable sys-usb.

Of course, I do nor believe all this cancels the firmware attack issues at all, but may be wrong here.
Is there someone more knowledgeable than me that can elaborate on this?

i have not tried the “minimal” distributions yet. Supposing there is a pdf on the flash drive, or whatever, does debian-minimal include a pdf viewer to view it with? (and probably libreoffice or something to view doc files)

the minimal template is for the sys-usb. then you can mount the block device in another (maybe standard template) dispVM

i have not tried the “minimal” distributions yet

there is a thread on the forum that is very useful as a starting point:

so you can give it a try. I thinh this is a very good approach for sys-net, sys-usb, sys-firewall …

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.

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.

1 Like

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)