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

91–100 of 104 posts

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

#91

Post by majorchord »

rpdillon wrote: post #76
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…

> 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 vi…

Theo and Linus' prolonged public attitudes are exactly why I boycott OpenBSD and Linux.

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

#92

Post by majorchord »

tom_alexander wrote: post #46
jwrallie wrote: post #7

Earlier quoted context omitted.

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 standar…

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

I would argue non-safe binaries are not safe in a container either. And even with full VMs, there have been an embarrassing number of escape exploits over the years.

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

#93

Post by deathanatos »

zzo38computer wrote: post #77
deathanatos wrote: post #75

Earlier quoted context omitted.

> 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 c…

Well, so there's two other problems with system (and popen):

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(""), then whatever those problems are, system(3) is going to share them.)

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

#94

Post by amarshall »

user_7832 wrote: post #54

Mini tangent: Could someone explain to me why Qubes is used for security, when (from what I understand) Jails on BSD is significantly more robust/safe/has a much smaller exposed area? Is it just "everyone's using linux already; here's a safer linux"?

Qubes uses VMs, Jails use a shared kernel. So I wouldn’t say Jails are safer nor that they have a smaller exposed area with regard to host isolation than VMs.

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

#95

Post by ipdashc »

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?

I feel like he is. VM breakouts are vastly rarer than kernel LPEs, aren't they?

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

#96

Post by devhunt-org »

It’s a good reminder that security boundaries are only as strong as the small utilities around them. The vulnerability is especially interesting because the dangerous behavior isn't in the main virtualization layer, but in something as mundane as error reporting.

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

#98

Post by throwawayffffas »

tdb7893 wrote: post #89
jervant wrote: post #66

Earlier quoted context omitted.

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

It's always gendered in the singular, very rarely people may use the singular in a non gendered way and usually this conversation that we are having follows.

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

#99

Post by throwawayffffas »

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?

Hardware graphics acceleration can work, it just needs a bit of fiddling and opens a few attack vectors. I don't legitimately know if there has ever been a viable attack through a shared pci device though.

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

#100

Post by throwawayffffas »

madushan1000 wrote: post #82
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.

They use Xens pci passthrough, you can setup a pci device to be assigned to a vm.

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.

Post reply on HN