Theos is a very opinionated and not necessarily wrong, but I feel also a bit too reductive given we are eternally having to deal with compromises of some form.
The bug here is not related to virtualization, but a footgun as old as C stdlib: system() that doesn't take arguments separately, and instead relies on shell escaping by the application.
I hope when people read this though they understand this is a communication style; they're clearly trying to strongly discourage people from thinking they are suddenly protected. Effective? Maybe at one time, where "macho dev energy" was a thing. Today, not so much. You can tell they mean well because the intro sentence is actually pretty cheeky!
This is less of a virt/x86 bug and more of a "don't call system() on arbitrary user input" bug.
.. incidentally, OpenBSD also provides one of the clearest examples of how the excuse "calling system() is fine in my case, its totally not arbitrary user input" is deluded just the same, see CVE-2020-8794.
That is sphincter tightening to read. Have to point out how amazingly well their bulletins handles communication. Clearly describes the issues, how users are to act, etc. in, what I feel, is an easy to grasp language, even if one’s not in the weeds that much. In fairness though, I do still have some past memories concerning Qubes architecture from way back, so maybe my assessment is wrong and this is still not that straight forward to grasp for most.
Wow, 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.
The worst part is that in 2020 they explicitly documented that the remote filename is attacker controlled,but still allowed it to reach system()
This is C security 101: never pass untrusted input through a shell. This should have been caught in the review!
The worst part is that in 2020 they explicitly documented that the remote filename is attacker controlled,but still allowed it to reach system()
That is C security 101: never pass untrusted input through a shell. This should have been caught in review!
I 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.
> Important: At this point, you still don’t know whether the key you just imported is the genuine QMSK or a forgery. In order for this entire procedure to provide meaningful security benefits, you must authenticate the QMSK out-of-band. Do not skip this step! The standard method is to obtain the QMSK fingerprint from multiple independent sources in several different ways and check to see whether they match the key you just imported. For more information, see How to import and authenticate the Qubes Master Signing Key.
It looks like Qubes is ran by people who take security seriously, which is refreshing.
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.
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.
Peculiar stuff. I'm always skeptical of these security Linux distributions, but this bug is so bad that it seems like an infiltration of Qubes at best or Qubes being a honeypot at worst.
Theos is a very opinionated and not necessarily wrong, but I feel also a bit too reductive given we are eternally having to deal with compromises of some form.
I hope when people read this though they understand this is a communication style; they're clearly trying to strongly discourage people from thinking they are suddenly protected. Effective? Maybe at one time, where "macho dev energy" was a thing. Today, not so much. You can tell they mean well because the intro sentence is actually pretty cheeky!
.. incidentally, OpenBSD also provides one of the clearest examples of how the excuse "calling system() is fine in my case, its totally not arbitrary user input" is deluded just the same, see CVE-2020-8794.
Especially as more and more virtualization functions move into hardware, not using them as a second security barrier seems foolish.
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.
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?
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.
There is an Issue for that: https://github.com/QubesOS/qubes-issues/issues/7051
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.
> Important: At this point, you still don’t know whether the key you just imported is the genuine QMSK or a forgery. In order for this entire procedure to provide meaningful security benefits, you must authenticate the QMSK out-of-band. Do not skip this step! The standard method is to obtain the QMSK fingerprint from multiple independent sources in several different ways and check to see whether they match the key you just imported. For more information, see How to import and authenticate the Qubes Master Signing Key.
It looks like Qubes is ran by people who take security seriously, which is refreshing.
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.
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.