I read in diagonal the content of this thread and wanted to clarify a couple of simple things, following some random risk assessment, costs of exploits to target random users and some normal paranoia when someone feels targeted, loosing sometimes common sense (not attacking anyone here).
- The easiest attack to see remote content of screen is binoculars, where having chain of exploits to obtain persistence to dom0 and grasp screen content and exfiltrate would make a user really targeted.
- random mouse movements is normally consequence of Bluetooth mouse battery dying, precise movement with point and clicks are a total different story, and filming those would be an interesting proof of anything. Most of the time, those proof lacking raise cynicism, for a reason. There is no way someone could not film those in 2022. And when that happens, cutting network and having the behavior stop at the same time could be considered proof.
- Qubes should not be able to write to system BIOS nowadays. Simply because writing to BIOS requires IO access that Qubes doesn’t have from qubes (the qubes have really limited access to real hardware) and where dom0 being compromised would also need to have access to SPI IO (that would be
iomem=relaxedat the very least) or physical access, which would be more probable otherwise again talking about chain of exploits to gain persistence. - People mix a lot of concepts, including open source firmware and absence of binary BLOBS. On that I will be really succint here, but there is no such thing with recent hardware that is Open source firmware without blobs AND compatible with Qubes OS. Qubes OS is compatible with x86, and x86 requires ME/CSME+FSP on Intel side or AGESA+PSP on AMD, without talking of blobs on SSD drives and Graphical cards. I hear you being positive about freedom-roadmap, but it is important to differenciate marketing speech from reality and this is difficult to digest. There is user-ownable hardware (kgpe-d16 being the only one I know that can boot Qubes OS without any binary blobs in firmware nor co-processor nor AGESA) where other open firmware enabled hardware are not supported by Qubes (Talos II is such platform, but has yet no Xen support). There is G505s, but without TPM nor enough SPI available flash space available and to be honest, that laptop is rare to get any hands on. Outside that there is older hardware with open source firmware (everything natively initialized, like the thinkpad X200 and similar) but those don’t meet Qubes Requirements (no hardware isolation : vt-d2). So the point here, at least to me, is to raise consciousness on the state of the actual hardware being produced and sold, so that people can be angry (and take action) about that and start to realize that without a clear stance and demands, that will not happen out of the blue and new hardware will be less and less user-ownable, controllable, repairable and most importantly, auditable.
So basically, there is multiple ways to deal with this. Some have been covered here and in so many other threads of this forum. I will retaliate some:
- Your vault’s qube’s KeepassXC don’t have to show on screen passphrases that were generated. You could generate them and copy paste them without any visual of them ever being displayed. That is if your only threat is binoculars/shoulder surfing/recording and replay.
- You could move around, hide yourself from plain sights and see if the threat is still present. Confirm that it is linked to a physical place or if it is linked to network access.
- You should get a machine that permits you to own it yourself, learn how to flash that hardware and then externally verify the state of your own firmware and externalize proof of persistence.
- Fresh install Qubes. Enable dom0 root volume snapshot on shutdown. Even multiple ones to keep multiple states you will be able to compare against from a filesystem content level. And report about them, and the content of scripts/binaries that were deployed without your consent.
- Tightly monitor network traffic externally. “PCAP or it never existed” is still a valid saying even today. Having network traffic, even encrypted, while having only your vault vm open should be a real concern (that requires a bit of analysis and is not so easy to accomplish, but should be more then enough to show proof, outside of NTP traffic and repository related traffic from dom0 getting available updates from its defined updatevm).
Other than that, the only other path is to believe.
Believe you were hacked but not being able to prove it.
Or believing that by buying a new laptop you will be safer, for which UEFI proprietary firmware is the worst mess that ever existed in my opinion, and will protect you from your threat model.
Nowadays, firmware security is shifting toward attesting integrity of non-auditable blobs. Not really into open sourcing them anymore. Some open source EC controllers as part of their freedom-roadmap. Some continue to claim unattainable goals keeping their old roadmaps. But no-one can neuter ME/CSME, open source FSP/AGESA but AMD/Intel themselves, and they won’t.
I find this alarming, but to answer your OP question: Qubes should help protect users from backdoors that resides in BIOS and device firmware, yes. Even if Qubes can protect users against themselves, if you pass along untrusted content between computers, and execute/read such content in trusted environments, there is always a risk that some passed content exploited vulnerabilities in those trusted qubes can one day land where it shouldn’t. If you leave your computer unattended without having any security mechanisms in place to protect /boot and you are targeted, the lowest cost for an attacker is the evil-maid scenario. It is totally possible and quick to accomplish to replace /boot’s kernel xen and initrd files, as easy as it is to modify grub.cfg configuration to break Qubes offered security defaults, and even have something there that would get persistence on first run to compromise dom0. That would be, to me, the easiest way to compromise a target’s system and bypass Qubes security mechanisms: compromise Qubes boot process through physical access of unencrypted /boot content. Low cost, effective to gain persistence on next successful boot, compromising even qubes root volume (dom0) even after Qubes dom0 updates that would eventually remove tampered binaries, if not measured/verified prior of being executed.