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.
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:
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 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:
USB keyboard / mouse / printer driver:
Advantage of running the de-authoriation script in sys-usb:
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”:
With “de-authorization script”:
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.
When to run “de-authorization script”:
or…
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.
thanks for the review and correction,
so then, considering these 2 facts:
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 ?
Yes to all, except DOM0 is only in jeopardy where there is no PS2 keyboard/mouse.
In addition, without de-authorization script a malicious USB device can infect the above components indirectly via USB device drivers. This significantly increases the attack surface and thus the likelyhood of successful attack.
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.
Since nobody is answering this question, I presume there are no genius ways of doing it. Here is my two cents:
If the maufacturer choses to impement the controller on FPGA or SOC, these chips usually have a fuse, that when blown would prevent anyone from reading back the firmware. This is usually done to protect Intellectual Property. I would presume that manufacturers would use the feature. Why wouldn’t they?
Let’s say the manufacturer chose to keep the firmware on an external serial flash, let’s say they didn’t encrypt it, and even provided a JTAG header for our convinience. What we are going to get in this case is megabytes of raw assembly code. And while it is possible to analyze the code to find one potential hole that can be exploited (this has been done), it is impractical to analize the code to assure there are no holes at all, and exploits are not possible (this is close to impossible to do even when you have well documented source code).
What we need is stateless hardware and open source firmware. I’m personally not aware of any such things being available on the market today.
Yes to all, except DOM0 is only in jeopardy where there is no PS2 keyboard/mouse.
i see, so in conclusion, the “de-authorization script” cannot completely secure all of these 3:
USB controller driver, USBIP server code, USB controller firmware.
It only decreases the attack surface.
is there a script / software, maybe usbguard or udev,
that we can install in sys-usb, performing several functions, such as:
prevent sys-usb, from attaching the USB device, to any components in sys-usb
Impossible: at least some components of sys-usb have to process the attached device, at the minimum process the fact that the device was attached.
auto scan for malicious content
Like any scan, this will only protect against known threats. Presumably, USB controller driver already patched to resist known threats.
okay, thanks information
at least, there is the “de-authorization script”, so far is the best temporary solution,
until there is better solution.
let me re-post from above
More details:
Microcontrollers usually have a protection mechanism that may optionally be used to prevent reading the internal firmware from a debug interface such as JTAG or SWD (serial-wire debug). A fuse bit in the microcontroller can usually be irreversibly set to enable this feature, however, many microcontrollers have not implemented such features correctly and so there are often ways to work around this feature. Furthermore, sometimes flaws may be exploited in the firmware itself to be able to read the firmware out. However, I would not depend on always being able to read the firmware.
Supposing you are able to read the firmware, are you expecting to audit the code for security exploits, or audit that the hash of the firmware code is the same as the manufacturers version of the firmware code? Since the workaround for each situation can be different, some of the workarounds may allow a compromised microcontroller to fake what firmware it presents through the debug interface.
I’ve done my best to read and understand this. I won’t throw in my two cents on solutions. BUT
Has anyone tried lobbying manufacturers for the sorts of USB controllers in question?
Surely purism, system76, pine64, ?framework would at least be receptive to hearing these pleas?
In a broader sense- is there actually even a qubes hardware lobbying group whatsoever? I know theres a HCL list and maintainer (thanks Sven).
But outside of what does and doesn’t work, people talk about wishlists often. Is it anyones job to collate and present these things to manufacturers to influence what will be DESIGNED to work?
If we could get our preferred laptop manufacturers onboard maybe they’d have enough clout to make it worthwhile? I was similarly thinking about someone devoting a lot of time to getting access to and testing qubes on machines from all manufacturers.
Is there any funding for that kinda shit? I’d do that job.
Yes, I did. I think Purism will make more USB controllers in the new version, because they have always been serious about Qubes support.
Big respect unto yous.
I have a general question about this. Suppose that a system has its firmware infected, perhaps from an untrusted USB drive.
If one has access to the original firmware and flashes the system with it, would that fully return the system back to its original secure state?
That could be the ultimate safe procedure for using an untrusted device, even though it’s not practical.
A attacker could potentially write firmware that would pretend to update, but really didn’t.
Ideally hardware would have a “out of band” way of verifying the firmware is what you expect (Meaning that the verification does not run from the same firmware that you are trying to confirm, and hopefully on read-only memory). In the cell phone world, at least from what i’ve read so far it sounds like the newer pixel phones can do something like this (this is implied by the “audit functionality” of pixel 6 phones)
It would be great if something like that could be done for USB, but considering the cost of a normal USB card, and the additional cost of adding external audit functionality, it’s unlikely to be practical for more then one or two manufacturers to do this as a niche market. (unless the world starts demanding that type of functionality)