Malware escaping an AppVM sandbox: Risk vectors for dom0 from a compromised qube?

If a nation state actor compromises a qube via the network, how might they use that compromise to get access to dom0 and/or other qubes?

This might (or might not) be a (partial) answer:

In this case, what hypothetically happens is that the nation state actor is unable to remotely hack Dom0, but inserts code through a compromised VM which crashes Dom0 and the whole the system. Then, this actor posts instructions on stack exchange or somewhere else for “fixing” the system in dracut, which modifies Dom0 (using search engine keywords that the victim would look for).

You can see that after “attempting to fix” using instructions found “somewhere” online before this forum was created, dom0:dm_43 - qubes_dom0-pool00_meta0 appears. I don’t know what that means and I’ve not seen it since. This could just be one scenario, or maybe just the paranoia of a Qubes user :upside_down_face:

Why would someone try to take your computer down when they can get your credit cards, bank account, property etc…

I get temporary hacks in VM’s 2-3 times daily and Dom 0 pawn once a month. Take care of fundamentals like accurate time, RNG etc… and you will be hacked A LOT LESS… See how a GPS can provide both (accurate time, and RNG)

If they got in through the network then, depending on the exploit they might have access to each networked VM.

For non-networked Qubes VMs or Dom0 Xen/Qubes exploits, CPU + RAM related attacks. Or indirectly maybe through updates.

How would an update attack be executed?

Nation states don’t like former slaves who escaped the plantation, and help others escape.

You get malicious packages or outdated packages.
Vulnerabilities in the package management software.

1 Like

If I’m updating thru the Qubes update module, who/what would have to be compromised for an update attack? Could it be possible that a single IP was targeted for that update attack, while not compromising the Qubes’ user-base?

I don’t know if that is possible, but you can use Tor if you are worried about this happening.

The IP would be the exit node of tor. If bad actor knew the update was coming thru that IP, would a man in the middle attack be possible thru the Qubes update module?

This would not target a single user, naturally.
In most cases, TLS will prevent MITM, and most repo definitions use
https.

Update attacks can take place through compromised packages, even when
they are signed and delivered via TLS.
The signature validations attest only that the packages you install are
those that were signed on the repository, and there are attacks on the
validation process. In any case the signatures say nothing about the
qualities of the package.

I never presume to speak for the Qubes team. When I comment in the Forum or in the mailing lists I speak for myself.
1 Like

Historically have we seen this attack on Qubes? And if so, how long before it was discovered? And how was it discovered?

What would be the “canary in the coalmine” that would signal a compromised machine as early as possible?