RowHammer mitigations on Qubes?

The pandavirtualization blog article suggests otherwise. But that is from 2017 and I’m confident it has been fixed.

@unman: Please correct me if I’m writing gibberish. I’m a greenhorn when it comes to binary exploits, rootkits, OOB-read/write kernel exploits, C++ or C-dialects in general. Actually I’m a greenhorn in a lot of things but everybody started small I believe.

To my understanding, if you can arbitrarly write to RAM you can inject and run code with the privileges of the process - or if the code is running in kernel mode as the almighty kernel.

Running it in a virtual environment and running it bare-metal is not the same, you can’t use the exploit unless there is a way to discover the physical memory space used.

You don’t inject code into memory, you “hammer” one area of memory, which can result in electrical leakage flipping bits in another part of the memory. If you know how the memory is mapped, you can use it to glitch execution resulting in privilege escalation.

6.3 Cross-VM Row Hammer Exploitation
[..]
6.3.2 Integrity Attacks
[..]
Particularly, the victim was the management domain in Xen, the Dom0.
[..] 
Once the signature was found, the adversary immediately replaced a five-byte
instruction “0xe8 0x1b 0x74 0xfd 0xff” (binary code for “callq pam_authenticate”)
with another five-byte instruction “0xb8 0x00 0x00 0x00 0x00” (binary code for
“mov $0 %eax”). Note here even though the memory page is read-only in the
victimVM, Dom0, the adversary may have arbitrary read/write access to it without
any restriction.
[..]

In the paper the attacker writes to an opensshd process to bypass pam_authenticate().

[..]
The modified code assigned %eax value 0 directly, without calling pam_authenticate(),
so the authentication will be bypassed.
[..]

In Qubes a different process would have to be used, i.e. crond or meminfo-writer. Writing five bytes would not suffice, one needs about 160 bytes or so for

/usr/bin/sh -c "qvm-run --pass-io pwnedVM 'cat /home/user/.badly_hidden_rootkit' > /tmp/librootkit.so && echo /tmp/librootkit.so >> /etc/ld.so.preload"

and another 30 bytes or so to run the execve(char *filename, char **argv, char **envp) syscall.

You can call that privilege escalation if you like, I’d like to call it game over. :wink:

7 Discussion on Existing Countermeasures
Row hammer resistance with hardware-assisted virtualization.
[..]
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].
[..]

Good to know. So we could answer the question if RowHammer poses a threat to QubesOS with:

To our best knowledge it does not if you use Qubes 4.1+ with HVMs and PVHs only.

edit: no sudo needed as crond and meminfo-writer already run as root.

1 Like

In most qubes user and root has access to the same files, and by default you can use sudo without knowing the password. Privilege escalation is not a big deal, the attack most likely had root access when they got access to the qube.

The important question is if you can use row hammer til break out of a qube, that’s when the game is over. I don’t think you can use row hammer to break out of a qube and get access to dom0, but I could be wrong.

It used to be possible.

Me, too. That’s the funny part of IT-security. We consider QubesOS and Xen to be reasonable secure, but we could be wrong. And the NSA is not going to tell us if we are wrong.

This is one of those edge cases that I haven’t seen discussed yet and should maybe be looked at. It’s tough to think of absolutely every vector but when the issue is raised it should be probed further.

There’s no Qubes zero-day or bug bounty that I’ve seen maybe there should be one to handle edge cases.

The vulnerability is actually a Xen issue and is mitigated on QubesOS as long as you use HVMs or PVHs. If I understood correctly PVHs are like HVMs but without Qemu to reduce attack surface.

Can’t find a bounty programm there. As Xen is used in deployed in date centers worldwide I assume that the zerodayinitiative would reward noteable findings.

For such a small distro I believe the QubesOS team is doing a tremendous job. Another team I admire is Google’s Project Zero.

Especially after Project Zero got the “Lamest Vendor Response pwnie award 2022” which totally discredited “Black Hat”.