I don’t think you understood my question. Obviously letting an infected system update itself is generally unsafe. I was not trying to get into the topic of things like Intel bootguard which if as far as I understand is supposed to prevent firmware malware but doesn’t really work. Though I might be completely mistaken.
I meant using an external flashing device while the system is powered off. Then no need for some kind of builtin auditing so long as the firmware source is valid, though that would be very useful.
I see. That makes sense to me. Out of band firmware updates sound even better. (“out of band” meaning that compromised firmware won’t be responsible for the firmware update mechanism internally)
Maybe the trick would be to look at individual microcontrollers that get used in lots of products, and see if there is a 3rd party way that out-of-band firmware updates, or out-of-band firmware auditing could be implemented at a reasonable cost to peripheral manufacturers.
If not, maybe try to add it to the RISC-V microcontroller design?
So my question is if that would be a reliable technique, that someone could apply today if they wanted?
Of course it is hardly an ideal solution to have to open up the system and physically flash chips.
My only comment on the out-of-band suggestion (as a future solution) is that it should be fully open source. So I guess if that is some kind of ROM then it should be verifiable against an open source code listing.
Note that I would consider manually re-flashing things (when the firmware does not run the “load new firmware function” one method of doing out-of-band updates (I.E. were talking about the same thing, but I’m just using a more generalized terminology)
I’m not sure at this time how to implement a automated out-of-band solution that would be maintainable and affordable.
I have also been interested in the subject and I realize this thread is fairly old but I think I have something to add, in case anyone cares.
Before plugging flash drives found in the parking lot, please note that no software measures can save you from a USB Killer device.
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?
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.
The actual bigger (kind of) philosophical question is what is a trusted USB device, especially in the context of Qubes OS where one explicitly distrusts everything except dom0.
I would like to see Void Linux (or something equally simple), or even BSD, running in dom0. Will this happen? No, and for very good reasons. And there are so many different use cases for Qubes, some of them pretty ridiculous (Windows, gaming, GPU pass-through) … that seem to snuff the idea of a usable, strictly compartmentalized, highly secure OS, in favor of frivolous distractions.
Great links there @qubist !
I’ve been meaning to look into this and it indeed seems like this is hugely overblown, especially if you’re running QubesOS without a USB keyboard, even with our “frivolous” dom0 base and Windows qubes
@ddevz It’s probably worth it to include in your OP, though likely it can’t be edited anymore. In short: it’s impossible to edit the USB controller’s firmware by plugging something into the USB port.
And there are so many different use cases for Qubes, some of them pretty ridiculous (Windows, gaming, GPU pass-through) …
Why is running Windows or gaming (without GPU pass-through) in a VM ridiculous? Are you saying it would be less ridiculous to run those on (separate) bare metal, allowing them unrestricted access to hardware, or do you mean something else? I hope you can clarify, as I need to run some Windows software which has no Linux version.
that seem to snuff the idea of a usable, strictly compartmentalized, highly secure OS, in favor of frivolous distractions.
I am questioning how dangerous using a USB keyboard actually is, because even if we assume a keyboard is somehow infected with BadUSB, what can it actually do, except type?
The fact that it may represent itself as another device (e.g. a network card) does not mean it actually has the instruction set to be a network card. So, it can only type commands. A PS/2 keyboard can do the same. So, what’s the difference?
To my mind, the process of installing Qubes OS from a USB drive is much more of a problem because:
The installer is stored on the USB drive unencrypted, i.e. the firmware of the USB drive has full access to it and can modify it. Additionally, a specially crafted USB device could probably infect the BIOS/UEFI.
That firmware is proprietary in almost all cases. Even if it is not, one still needs to somehow be able to verify what exact firmware the USB drive uses, or flash one’s own build of it. Then the question is - how does one do it? On what hardware and OS? How is that hardware (and everything related to it) guaranteed that it itself is clean and won’t infect the USB drive? IOW, how does one “start clean” along the chain?
So far, the only FOSS/H USB drive I know of is Nitrokey Storage. Its unencrypted storage, however, is only 2 GiB. So, to be able to put a Qubes OS installer on such device, first one needs to rebuild its firmware and reflash it.
Indeed, as long as the user has a sys-usb (w/o usb keyboard for dom0) the damage that a BadUSB can do is quite limited; in fact, if nothing else is connected to those controllers and that VM right now, then the threat is almost negligible.
Closed source USB stick firmware does indeed become a problem if installing an OS, yes…flipping the write protect switch does not guard against bad firmware and is at the mercy of the firmware anyway (at least potentially); we need more open source USB sticks like Nitrokey Storage!
I think we’re off-topic, but here goes: nobody wants to re-invent the wheel, right? So the devs, who put a lot of work into building the system, want to avoid re-inventing the wheels that work well in Fedora, probably their favorite distro - and this is a “very good reason” imo.
Why is running Windows or gaming (without GPU pass-through) in a VM ridiculous?
Off-topic again: for me, it is. If you run Windows, your focus is not on security nor privacy. Trying to push these things into QubesOS is not what QubesOS should prioritize. Again, my opinion.
Probably this discussion should happen in the other (quite active) thread, about “what would you like to see in Qubes”.
Sometimes one has no choice…an app is not available in linux form, for instance.
In those cases one can run windows in a network-isolated qube–i.e. one with no networking. That should be secure enough.
(Presently, for whatever reason, my printer driver in Linux is not working, so I am having to run windows just to print documents. But again it’s an isolated windows VM [it had better be, it’s Windows 7]. Until my printer driver broke, I hadn’t run windows in months).
Now if you want to run windows to surf the web or do other things online, I will agree with @barto: you’re probably not thinking about security first. I imagine there are things that must be done online and can only be done with windows, but I don’t know of any and hope I am never in that situation.
I disagree: Even if you allow your Windows VM to go online, it doesn’t make your other VMs or dom0 compromised or insecure. The Windows VM itself might be compromised though.
I went ahead and tried to edit it to add a comment like that and if there is a way for me to edit it anymore, i don’t see how. I think you are correct about me being locked out of it
@ddevz I assumed you were talking about the first post in this topic and turned it into a wiki. This means you should be able to edit it now (there is otherwise a 30-day limit to edits).
Of course, if that’s not what you meant, please let me know!
