Mitigations for resource usage covert side channels in qubes

General Discussion
1

When using shared resources, one is able to modulate data into the usage pattern. This is bad.

The other day i thought a bit on how to extract information from a vault qube.

The first thing that came to my mind:

“If i utilize the CPU in qube A, i may be able to detect that in qube B by measuring the time when qube B is rescheduled. I should be able to transmit information over this channel.”

Sure: The adversary need to have RCE in both qubes, but think big. Think supply chain attack for example.

Before i got to write a POC i used my favorite search engine and sure enough i am not the first to come up with that idea. Here is a POC.

I have not attempted to use this in qubes.

A few questions:

  1. How does the xen hypervisor schedule? Does scheduling change when load changes? My suspicion: Yes.
  2. What other side channels could be utilized? caches might be covered by existing mitigation, but maybe RAM or PCI devices?
  3. What are our mitigations?

Regarding mitigations:

Things anybody can do now:
Pause critical qubes like password vaults when not in use.

I cannot think of one solution that would fit all without impacting performance in an extreme way, so maybe the best approach would be to monitor ressource usage of domUs and try to detect patterns.

If the attacker cranks down SNR to avoid detection this would make the attack much harder to detect, but take much longer. This might be a worthwhile thing to explore in addition to pausing. May also detect something like Rowhammer.

What are your thoughts on this?

4 Likes
2

And, vice versa, pause all other qubes when doing something with vaults:

3 Likes
3

Thanks for the link!

Pausing all other qubes surely would mitigate the attack greatly, but has more implications that just pausing the vault. It is highly dependend on what one does with qubes, while only pausing the vault basically is not.

I think implementing this as a simple bash script in dom0 is very easy and i will play around with that and see what is breaking.

However, i think this has other implications, as this would leak metadata about when highly sensitive operations are performed to all qubes, making this specific information much more vulnerable.

With this knowledge an advanced adversary could leverage other means of exploitation. Especially regarding the anonymity side, this can be abused for a great number of cross referencing and confirmation attacks on anonymous identities or even singular browsing sessions, giving more leverage against (hypothetical) Tor attacks.

I have not concluded what my stand on this is, but will think about it further. :slight_smile:

In the meantime: Is there a reason, why the pause function is called “emergency pause”? This sounds a bit like a last resort thing, and not like a regular operation.

Some other things i came up with:

  1. The most vulnerable information are in the holy grails: Our password safes. The location and kind of information is blatantly obvious to unsophisticated and thus small malware.
  2. Extracting useful information out of (my) other vaults, like multi TB big libraries are impractical unless the adversary knows exactly what he is looking for.

Based upon this, i came up with two other ideas:

  1. Decoy information: One could flood the keepass with a lot of decoy keys. This would only affect the (time) cost of attack linearly. One needs to make sure, to not have identifiers for the key like “monero wallet key” as names. With my other idea, this scales with O(n²) or even O(n³) (if i am not mistaken).
  2. Split information: Additionally one could create another vault based on a different template with a differen password manager that does hold the other half of the keys and the identifiers. Creating a correct password would need both vaults to work together, so your adversary would have to pwn both. His malware would need additional complexity, increasing the chance of detection.
  3. Another attempt would be to simply opt out of using vaults for passwords. Something like a hardware password manager, maybe even homemade that would simulate key presses is another option, but comes with other security implications.

A combination of all above mitigations might be envisioned. Or even an automated means of spawning new vaults, giving a theoretical advantage of O(n^n) which seems pretty significant, if the user can afford this with software diversity and ram usage.

1 Like
4

Unpopular take on this topic: if you have information in a vault that you consider critical enough to think about this kind of advanced threat levels: do not store it on a computer with Internet access.

Just use a separate air-gapped computer that you boot up if you require access to these passwords and transfer them by hand.
What should prevent an attacker this powerful from finding an escape-to-hypervisor exploit in Xen? Or from compromising your computer on a firmware level (BIOS/UEFI, Intel ME, graphics cards driver, …)?

1 Like
5

HEADS would be the measure to protect against BIOS/UEFI persistent rootkits. ME can be neutered. Graphics card is optional.

I agree with you RE: airgapping the p/w’s if the threat level is this high, but it is still a good exercise to see how much we can mitigate on our primary systems.

4 Likes
6

Great take on this, and i would mostly agree.

However…

My use case for a password manager is… well, managing my passwords for mostly online services. I could use a truely air gapped system for this, but i would have to manually type in the password. This is not great usability an chances are, that my passwords will get easier and shorter because of this.

Another option would be a “partially air-gapped” system, that yould communicate with my PC for example over QR-codes and a webcam or by emulating an USB keyboard, which i mentioned above. As long as there is enough entropy induced by this part of the system, the system is strong. To mitigate other unknown vulnerabilities, a combination of software airgap + hardware airgap could lead to more security than a hardware airgap alone.

This is a very good question.

My opinion on this is, that a xen hypervisor escape exploit would be too expensive to burn on me/us.

Organizations that deploy this high level exploits always have systems in place to weight risk against gain. From what i have heard, the operatives do not get permission to use a secret exploit if there is a realistic chance of it getting caught.

We are the reasonably paranoid ppl that virtualize everything and run full audit mode. On any glitch we safe all the logfiles and try to find out what happened. This is a very high risk setting for using such an exotic and hopefully rare exploit. → Not worth the risk.

Going into firmware level seems easier/cheaper/safer to me. I am not into that very much, but against BIOS you have coreboot for better security, also flashing firmware or BIOS from within domUs seems unlikely to me, but i am not expert here by any means, so feel free to correct me!

Oh and one last thing:

I am just thinking of this because of scientific interest, not because i think such an attack is reasonable to be waged against me personally as i, like everybody else, have nOtHiNg To HiDe.

2 Likes
7
2 Likes
8

ouch…

Thanks for the information!

9
10

[1] does automatic pause & shutdown.

[1] https://github.com/3hhh/qidle