Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

qubes-os.org

Post reply on HN
Print view View original

71–80 of 104 posts

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

#71

Post by iugtmkbdfil834 »

matherial wrote: post #42
iugtmkbdfil834 wrote: post #33

Earlier quoted context omitted.

But, and this is the important part, is he wrong?

Being right is not the most important part. If you're right but don't convince anyone, you've made no difference. 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…

I did not claim it was most important, but he clearly called out issues that haunt us still, because we did not fix the basic initial issues ( and we are actively making it worse now with AI slop -- we because, while I use llms, I am not arrogant enough to offer my contributions to emulation, virtualization and other foundational stuff ). The point is that he called it and all of us should do some soul searching as to why his words were ignored. Because if he was ignored because 'he was mean about it', the we are kinda screwed long, because anyone with a brain that can comprehend the issue, will likely have little patience for anyone, who can't see it or won't want see to see it for some contrived semi-social reason.

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

#72

Post by dvdkon »

sdcfgy wrote: post #43
Topfi wrote: post #26

Earlier quoted context omitted.

I feel that, in fairness, one should at least read Adam’s response, though ideally all subsequent mails: https://marc.info/?l=openbsd-misc&m=119320496730314&w=2 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. I…

I think it's pretty much spot on myself and applies to more than virtualization based on the last point. It really suggests that further complexity and abstraction is not a good security posture. And I agree with this from extensive experience (embedded, defence). 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…

Sadly complexity is unavoidable for most real-world usecases. Just see how so many people interested in de-Googled phones balk at the prospect of losing access to banking apps. Telling them to go use an OS that doesn't support Bluetooth isn't going to work, but hopefully you wouldn't say that means they should give up all hope of security.

Abstraction has served us well in managing complexity before. I wouldn't abandon it out of misplaced idealism.

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

#73

Post by iugtmkbdfil834 »

zvmaz wrote: post #35
iugtmkbdfil834 wrote: post #33

Earlier quoted context omitted.

But, and this is the important part, is he wrong?

I don't really know as the argument is mainly about how stupid people are... The technical argument is one paragraph ended with an insult, not much to make an educated and civilized opinion.

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..

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

#74

Post by sdcfgy »

dvdkon wrote: post #72
sdcfgy wrote: post #43

Earlier quoted context omitted.

I think it's pretty much spot on myself and applies to more than virtualization based on the last point. It really suggests that further complexity and abstraction is not a good security posture. And I agree with this from extensive experience (embedded, defence). 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…

Sadly complexity is unavoidable for most real-world usecases. Just see how so many people interested in de-Googled phones balk at the prospect of losing access to banking apps. Telling them to go use an OS that doesn't support Bluetooth isn't going to work, but hopefully you wouldn't say that means they should give up all hope of security. Abstraction has served us well in managing complexity before. I wouldn't aband…

Hey I'm quite happy to run my banking over TN3270 :)

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

#75

Post by deathanatos »

msm_ wrote: post #10

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…

> well-designed to be secure

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)

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

#76

Post by rpdillon »

sdcfgy wrote: post #43
Topfi wrote: post #26

Earlier quoted context omitted.

I feel that, in fairness, one should at least read Adam’s response, though ideally all subsequent mails: https://marc.info/?l=openbsd-misc&m=119320496730314&w=2 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. I…

I think it's pretty much spot on myself and applies to more than virtualization based on the last point. It really suggests that further complexity and abstraction is not a good security posture. And I agree with this from extensive experience (embedded, defence). 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…

> tone was appropriate

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.

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

#77

Post by zzo38computer »

deathanatos wrote: post #75
msm_ wrote: post #10

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…

> well-designed to be secure 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 prog…

The "system" function (and also "popen" function) are helpful, although they should be used carefully. You should only use it where the entire input (rather than merely a part of it) comes from a trusted source from the local user (and documented in a clear way that it does this), such as being entered interactively or from a user configuration file, or in some cases a entirely hard-coded string (although in such a case, often one of the exec functions works better), and to ensure that the security boundary is correct (e.g. you should probably avoid it if it is setuid). If it is necessary to pass additional data then you might use environment variables, pipes, temporary files, etc.

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).

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

#78

Post by Joel_Mckay »

progval wrote: post #69
artyomsv wrote: post #12

Earlier quoted context omitted.

Problem is not that nobody wants to do it, it is that GPU stack is exactly the kind of enormous driver surface Qubes exists to keep away from dom0. Second monitor does not really change that, somebody still has to trust the driver.

The driver could run in a VM and only display applications from that VM or a subset of VMs.

Most GPU drivers are an order of magnitude more complex than a CPU kernel.

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

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

#80

Post by woodruffw »

grommz wrote: post #41

The founder Joanna Rutkowska left QubesOS in 2018. All the code involved in this bug was committed by her successor Marek Marczykowski-Górecki. 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.

Is there some evidence that x86 is uniquely prone to exploitable memory corruption? I haven't seen it, if so.

> 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).

Post reply on HN