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

81–90 of 104 posts

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

#81

Post by upboundspiral »

woodruffw wrote: post #80
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…

The paper X86 considered harmful was about how the BIOS / Intel management Engine (now also AMD PSP), are completely opaque.

If the lowest layer is hidden, proprietary, there are infinite vectors for state actors to include their desired backdoors.

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

#82

Post by madushan1000 »

zby wrote: post #6

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?

This is sort of a solved problem with virtio native context. You can just run mesa driver in the virtual machine and proxy it's ioctl calls to host kernel gpu driver.

I'm pretty sure all the major GPU drivers in mesa now supports this feature.

Wonder why QubesOS hasn't adopted this yet.

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

#83

Post by negura »

iugtmkbdfil834 wrote: post #33
zvmaz wrote: post #21

Earlier quoted context omitted.

All I see is rudeness, insults, and arrogance sparkled with inklings of technical arguments. Worthless.

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

it's not right nor wrong, it's irrelevant. this exploit has nothing to do with the Xen hypervisor which underlies the virtualization in QubesOS

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

#85

Post by woodruffw »

upboundspiral wrote: post #81
woodruffw wrote: post #80

Earlier quoted context omitted.

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…

The paper X86 considered harmful was about how the BIOS / Intel management Engine (now also AMD PSP), are completely opaque. If the lowest layer is hidden, proprietary, there are infinite vectors for state actors to include their desired backdoors.

My understanding is that IME and PSP come more from the world of corporate compliance than anything else. In other words they exist for x86 because x86 gets deployed in corporate settings, and any ISA that attempts to occupy a similar niche will meet a similar fate.

(Compare ARM’s TrustZone, etc.)

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

#86

Post by negura »

polotics wrote: post #3

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

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

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

#89

Post by tdb7893 »

jervant wrote: post #66
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.

[flagged]

I feel like "guy" is weird in that I often hear people say "you guys" (and similar phrases) to groups of women but "guy" on its own is referring to a man at least 99% of the times I hear it. I'm curious if other people actually use it completely non-gendered (it's definitely gendered in the places I've lived in the US).

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

#90

Post by edelbitter »

_pdp_ wrote: post #29

Most security bugs are due to improper string validation and use.

(Obviously a take that does not get very far in lower level programming, but from the comfort of some abstractions away:) I like to think of buffer overruns, command injections and path traversal as all the same category of bug: type confusion. Nothing special. An no excuse to risk any of them, if the logic implementing them is expected to be called just O(1) times anyway.
Post reply on HN