Qubes OS flaw lets a compromised qube seize dom0 via file-copy error dialog

Qubes OS has patched QSB-118, a dom0 arbitrary code execution bug in the qvm-copy-to-vm tool. The attack surface is the qfile transfer protocol’s confirmation step: after a copy, the receiving qube sends back a status message that includes an error code and the name of the last file it handled. When an error is flagged, dom0 pops up a GUI dialog echoing that attacker-supplied filename. The trouble is how the dialog gets built — the filename is spliced into a command string and handed to system(), so the receiving qube controls part of a shell command running in dom0.

The supposed guardrail, sanitize_remote_filename(), only replaces non-printable/non-ASCII bytes and double quotes; it leaves shell metacharacters like backticks, semicolons, and pipes untouched. A malicious qube can therefore return an error along with a crafted filename and inject an arbitrary command into dom0. Because dom0 is the trusted control domain, that means full compromise of the machine. The exploit isn’t fully unattended — it requires the user to initiate a copy from dom0 to a qube the attacker already controls — but that’s a plausible action, and dom0 is exactly where such a slip is fatal. Notably, the VM-to-VM path is safe: the in-qube error reporter uses execlp() rather than routing through a shell.

All Qubes OS releases are affected. The fix ships in qubes-core-dom0-linux 4.3.22 for Qubes 4.3, moving from security-testing to stable after a brief validation window; users just need to update normally. The bug was reported by Tim C. It’s a textbook lesson in the danger of assembling shell commands from remote input and in trusting an allow-list sanitizer that never accounted for shell syntax.