Arbitrary code execution in QubesOS via copy-to-VM error reporting backchannel
1–10 of 104 posts
Re: Arbitrary code execution in QubesOS via copy-to-VM error reporting backchannel
#2Another 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.
Re: Arbitrary code execution in QubesOS via copy-to-VM error reporting backchannel
#3I'm still very impressed by qubes, and glad I'm not such a target that I feel I need the level of opsec it affords (on all my laptops).
Maybe someday AI-assisted killchains will be so widespread that Qubes is the minimal level for the (few?) still-local users of compute.
I would not have copied anything from dom0 to any another qube, the impact is low.
Re: Arbitrary code execution in QubesOS via copy-to-VM error reporting backchannel
#4Another 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.
> 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.
Re: Arbitrary code execution in QubesOS via copy-to-VM error reporting backchannel
#5Another 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.
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.
Re: Arbitrary code execution in QubesOS via copy-to-VM error reporting backchannel
#6I am still impressed by QubesOS track and I use it for my dedicated 'financials' laptop.
IMHO the thing that is holding back QubesOS is the lack of hardware acceleration for graphics - maybe now when dual monitor setups are getting popular this could be a workaround for the security considerations?
Re: Arbitrary code execution in QubesOS via copy-to-VM error reporting backchannel
#7I am still impressed by QubesOS track and I use it for my dedicated 'financials' laptop. IMHO the thing that is holding back QubesOS is the lack of hardware acceleration for graphics - maybe now when dual monitor setups are getting popular this could be a workaround for the security considerations?
I dropped QubesOS once exactly for that reason in the past but now I’m running it again on a separate computer.
Even with all its drawbacks, there is something really nice about being able to run different applications over Tor, VPN or plain internet simultaneously, the ability to isolate non-safe binaries and being able to backup your VMs easily.
I wish a similar distro would be made based on KVM so that the standard kernel could be used. It would be great for compatibility.
Re: Arbitrary code execution in QubesOS via copy-to-VM error reporting backchannel
#8Another 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.
> 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.
It's for an the "File copy/move error" error dialog.
Re: Arbitrary code execution in QubesOS via copy-to-VM error reporting backchannel
#9I am still impressed by QubesOS track and I use it for my dedicated 'financials' laptop. IMHO the thing that is holding back QubesOS is the lack of hardware acceleration for graphics - maybe now when dual monitor setups are getting popular this could be a workaround for the security considerations?
I dropped QubesOS once exactly for that reason in the past but now I’m running it again on a separate computer. Even with all its drawbacks, there is something really nice about being able to run different applications over Tor, VPN or plain internet simultaneously, the ability to isolate non-safe binaries and being able to backup your VMs easily. I wish a similar distro would be made based on KVM so that the standar…
> I wish a similar distro would be made based on KVM
There is an Issue for that: https://github.com/QubesOS/qubes-issues/issues/7051
Re: Arbitrary code execution in QubesOS via copy-to-VM error reporting backchannel
#10Wow, this is serious. Makes you think, that even though QubesOS attack surface is so tiny (well-designed to be secure) there are still vulnerabilities to be found.
Worth noting that (as I understand) this vulnerability occurs only when doing copy-to-VM from Dom0:
>Note that the VM variant of `qvm-copy-to-vm` is not affected, as its version of the error reporting function does not use `system()`:
Since you should not use Dom0 for regular work, and definitely not for interacting with likely-to-be-infected VMs, the scope of this attack is smaller than it sounds. On the flip side, when it works, it elevates privileges straight to Dom0.