Arbitrary code execution in QubesOS via copy-to-VM error reporting backchannel

Re:Arbitrary code execution in QubesOS via copy-to-VM error ... by charcircuit on Sunday August 30, 2026 @05:41AM (#49497145)

Another example for why system() is so dangerous to use.

I also don't understand why it needs to show the dialog in dom0. If you have the option to handle attacker controlled input on the unprivileged side, you should do that instead of putting a lot of logic on the privileged side.

[ Parent | on HN ]

Re:Arbitrary code execution in QubesOS via copy-to-VM error ... by delamon on Sunday August 30, 2026 @06:13AM (#49497317)

The code is sloppy. They check existance of kdialog binary using full path; next step they rely on PATH search by shell. If would've been much safer to just do execve directly.

[ Parent | on HN ]

Re:Arbitrary code execution in QubesOS via copy-to-VM error ... by HackerThemAll on Sunday August 30, 2026 @06:11AM (#49497307)

> why it needs to show the dialog in dom0

I think it's the "secure screen" that cannot be manipulated by the malware in a VM. I'd expect a password entry dialog to also be handled like that.

[ Parent | on HN ]

Re:Arbitrary code execution in QubesOS via copy-to-VM error ... by charcircuit on Sunday August 30, 2026 @06:38AM (#49497455)

It's for an the "File copy/move error" error dialog.

[ Parent | on HN ]

Re:Arbitrary code execution in QubesOS via copy-to-VM error ... by danielheath on Sunday August 30, 2026 @08:26AM (#49498076)

If you're going to put the graphics and NIC into separate VMs, surely the secure screen can be another of those semi-privileged VMs rather than part of dom0

[ Parent | on HN ]