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.
While I suppose this doesn't say the design isn't secure, system() is one of those calls that has no place in modern code. It is insecure by its design.
> Any user input that is employed as part of `command` should be carefully sanitized, to ensure that unexpected shell commands or command options are not executed. Such risks are especially grave when using system() from a privileged program.
(—man 3 system)
Strings passed to system or popen should not be constructed by combining other strings; they should be directly unchanged from whatever trusted source it comes from.
The specific use documented in the article is a situation where I should think that you should not call the shell (since the command includes untrusted input, and also because there might be a better way to display the error message).
There are additional possible security issues with such things though, whether you use the shell or execute directly, some of which are due to the use of text rather than binary data for communication (although changing that won't solve everything).
For example when you take a screenshot with xfce4-screenshooter, the file is saved to dom0, and you have to use qvm-copy-to-vm to move it to a (less trusted) qube to do something with it. That's the most frequent use case, at least for me.
Joanna seems to be a genuine good guy, she once wrote a paper titled "Intel x86 considered harmful". That's why Huawei and the Chinese government aren't even trying any more to make western CPU architectures secure, it's a hopeless cause.
> That's why Huawei and the Chinese government aren't even trying any more to make western CPU architectures secure, it's a hopeless cause.
I suspect there are much more boring reasons for this, ranging from licensing to geopolitics (i.e., it being useful/valuable to have a domestic base of engineers who can design an ISA).
If the lowest layer is hidden, proprietary, there are infinite vectors for state actors to include their desired backdoors.
> she
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?
[1] https://doc.qubes-os.org/en/latest/introduction/faq.html#is-...
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.
You'd typically copy logs, to open issue tickets etc.
> 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.
1. IME security teams want to run dumb linters over the code that look for such things. While uses such as the ones you describe are secure, the linter might be blunter than that. I'm not sure that's necessarily a bad thing: "this use of system(3) is secure" has a cognitive tax at review time, and as the code changes; often, I prefer the stance of "don't make me think" with regards to security: i.e., do the simple, trivially secure thing, not the complex, secure under the just-right conditions thing. Then we don't have to persuade (potentially non-technical) security teams, non-technical auditors, linters, etc. that are going over the code with blunt instruments.
2. (And much more minor) the entire execution of sh is often just wasted performance that an exec(2) removes.
(& yes, you are also right that even an exec(2), mishandled, can have its problems in some circumstances. But typically when the pattern is system("<shell that just runs what we'd exec(2)>"), then whatever those problems are, system(3) is going to share them.)
(Compare ARM’s TrustZone, etc.)
Theos is a very opinionated and not necessarily wrong position, but I feel also a bit too reductive given we are eternally having to deal with compromises of some form. Also, lest we forget, it has been two decades in the interim and oh so much has changed. In any case, this originated from their code, not virtualization, so it doesn’t really apply either way…
Regarding the two decades since and the numerous exploitable x86-64 and hypervisor bugs suggests he wasn't wrong and that the tone was appropriate for the severity of the problem.
Especially as more and more virtualization functions move into hardware, not using them as a second security barrier seems foolish.
.. 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.
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!
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.
These are all possible using light containers. For example, on FreeBSD I will spin up a jail which runs wireguard, and then I'll bridge that to another a jail. That 2nd jail is running entirely off wireguard without any other way to access the network. Since it is a jail, it is isolated. And backing up is as simple as a zfs snapshot and zfs send. I assume the same is possible on Linux.
There is an Issue for that: https://github.com/QubesOS/qubes-issues/issues/7051
I'm pretty sure all the major GPU drivers in mesa now supports this feature.
Wonder why QubesOS hasn't adopted this yet.
The vm runs it's own driver and has direct access to the device, you typically have to hide the device from dom0 for it to work flawlessly and hardware support is required. But I believe the kernels do not interact with each other in a direct way.
I used to have crashes on trying to restart a vm with a pci device attached probably related to resetting the device. But they seem to have resolved now days.
Abstraction has served us well in managing complexity before. I wouldn't abandon it out of misplaced idealism.
TDR said:
> You are absolutely deluded, if not stupid, if you think that a worldwide collection of software engineers who can't write operating systems or applications without security holes, can then turn around and suddenly write virtualization layers without security holes.
This comment wouldn't survive HN scrutiny. It's a strawman argument, and doesn't address the core point at all: does virtualization improve or degrade security, when taken as a whole?
Adam's response is great, and TDR is smart, but he's been a lightning rod for 20 years for a reason: he was doing hot takes before they were even called that, and this is a great example.
I work with a lot of great engineers with similar behavior. Their arguments are not personal, although they seem to be. They are just very passionate and care deeply about certain things (in this case operating systems security).
If you can get past the aggressive/offensive language they use and develop a relationship with them, they can be reasonable and helpful. That's been my experience.
No capabilities, or even a sane and useful way of adding capabilities with everything in ring 0, and the flat integer namespacing of users and groups just doesn't work for what userspace needs to do today - hence namespaces, which have introduced their own problems, because (no surprise) trying to graft a tree structure onto a flat integer namespace after the fact is a mess.
Virtualization tried to sidestep all that, but to make it fast the cost has been more driver interfaces to host ring-0 - remember what the original was? - and screwing around a whole bunch with particularly arcane facets of the core ring-0 security boundary, e.g. page tables.
It is a mess.
There is also the fact most GPU are a bodged on architecture, and fundamentally impossible to really secure in the case of CUDA rootkits.
Fast, but a bad design. This is why we can't have nice things. =3
Theo was right that virtualization is a comparatively shoddy security boundary. At the same time, it's flexible and capable in ways that now define the shape of modern IT.
Could we have replicated that by other means? If yes, then it's on Theo and other knee-jerk critics that they never proposed a better approach and settled for insulting people. If not, then maybe virtualization was a necessary evil. Or maybe everyone else is an irredeemable idiot, but again - if we reach that conclusion, is the world better off?
Stares at Go as about the only step in that direction...
Allow me to start by saying that you are wrong about 'mainly about'. The argument starts with an insult, but insult is minimal and it moves directly into the technical details. But, note that how much you are wrong about the paragraph, because what you want to focus is the insult. You are so wrong about it you effectively invert the proportions of presence of technical data to insult..
"HN: Professionally identifying 230% of posts from 2017 as LLM generated".
That said Panagram is trash for the opposite reason. Not that some people talked like LLMs before LLMs, but now a lot of people talk like LLMs because of LLMs.