Reminds me of Theo DeRaadt again: https://marc.info/?l=openbsd-misc&m=119318909016582
All I see is rudeness, insults, and arrogance sparkled with inklings of technical arguments. Worthless.
Arbitrary code execution in QubesOS via copy-to-VM error reporting backchannel
21–30 of 104 posts
Re: Arbitrary code execution in QubesOS via copy-to-VM error reporting backchannel
#22The 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!
Re: Arbitrary code execution in QubesOS via copy-to-VM error reporting backchannel
#23Reminds me of Theo DeRaadt again: https://marc.info/?l=openbsd-misc&m=119318909016582
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.
Re: Arbitrary code execution in QubesOS via copy-to-VM error reporting backchannel
#24Reminds me of Theo DeRaadt again: https://marc.info/?l=openbsd-misc&m=119318909016582
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.
Re: Arbitrary code execution in QubesOS via copy-to-VM error reporting backchannel
#25The 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!
Re: Arbitrary code execution in QubesOS via copy-to-VM error reporting backchannel
#26Reminds me of Theo DeRaadt again: https://marc.info/?l=openbsd-misc&m=119318909016582
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. In any case, this originated from their code, not virtualization, so it doesn’t really apply either way…
Re: Arbitrary code execution in QubesOS via copy-to-VM error reporting backchannel
#27it's kinda doomed at this point
Re: Arbitrary code execution in QubesOS via copy-to-VM error reporting backchannel
#28[flagged]
Re: Arbitrary code execution in QubesOS via copy-to-VM error reporting backchannel
#29Most security bugs are due to improper string validation and use.
Re: Arbitrary code execution in QubesOS via copy-to-VM error reporting backchannel
#30The 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!
Isn't it the case for all bugs? If they appear in the production software, it means that they passed the review. And obviously bugs shouldn't pass the review, but that's easier said than done.