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

Linux Zoom client proactively reading everything written to X11 clipboard

hachyderm.io

Post reply on HN
Print view View original

101–110 of 176 posts

Re: Linux Zoom client proactively reading everything written to X11 clipboard

#101

Post by rwmj »

bmacho wrote: post #97
rmellow wrote: post #6

Not the first time Zoom abuses privilege. A few years back, there was something about gaining root on MacOS via Zoom due to shady execution on their end. They've lost my trust since then, and I'll only run it sandboxed: https://gist.github.com/cielavenir/02f322e322a2a3555dbf2b38f... I always ask (1) why does an app require installation and (2) why would it require root? There are valid answers for both, but realistic…

> They've lost my trust since then, and I'll only run it sandboxed: https://gist.github.com/cielavenir/02f322e322a2a3555dbf2b38f ... On Linux/X11 even when you run a program sandboxed or as a different user if you use a master Xserver the sandboxed program still can listen and modify all your input/output including keyboard/mouse events and window content of every application.

That doesn't change that programs doing this can be shady (or very useful).

Re: Linux Zoom client proactively reading everything written to X11 clipboard

#102

Post by lxgr »

blake8086 wrote: post #67
wolvoleo wrote: post #25

Earlier quoted context omitted.

Yes Apple even blocked their app because they refused to fix it. Eventually they did and unfortunately they were allowed again. It wasn't really root as much as an open backdoor on a TCP port as far as I recall.

I worked at Zoom during this time. That's not what happened. Zoom used the same technique Cisco Webex did - they ran a webserver with an open port so that local "links" to a meeting could open on your own machine. It wasn't a backdoor. Apple flagged that as a potential security risk, so Zoom worked with Apple on how to safely remove only the webserver without affecting other functionality. We were happy that Apple wo…

> that there was almost no reaction from the tech community that Apple had software running on every Mac that allowed them to remove any binary they wished. (Which sure sounds like a backdoor)

Because that’s a documented feature (malware protection).

As a user, I generally like it, and in this case I’m fully aligned with their classification of Zoom’s behavior as a nuisance. A lot of malware developers justify their behavior as “just doing what their users want/need”.

Re: Linux Zoom client proactively reading everything written to X11 clipboard

#104

Post by wolfi1 »

rwmj wrote: post #101
bmacho wrote: post #97

Earlier quoted context omitted.

> They've lost my trust since then, and I'll only run it sandboxed: https://gist.github.com/cielavenir/02f322e322a2a3555dbf2b38f ... On Linux/X11 even when you run a program sandboxed or as a different user if you use a master Xserver the sandboxed program still can listen and modify all your input/output including keyboard/mouse events and window content of every application.

That doesn't change that programs doing this can be shady (or very useful).

but sandboxing would be quite useless

Re: Linux Zoom client proactively reading everything written to X11 clipboard

#105

Post by wolfi1 »

bmacho wrote: post #97
rmellow wrote: post #6

Not the first time Zoom abuses privilege. A few years back, there was something about gaining root on MacOS via Zoom due to shady execution on their end. They've lost my trust since then, and I'll only run it sandboxed: https://gist.github.com/cielavenir/02f322e322a2a3555dbf2b38f... I always ask (1) why does an app require installation and (2) why would it require root? There are valid answers for both, but realistic…

> They've lost my trust since then, and I'll only run it sandboxed: https://gist.github.com/cielavenir/02f322e322a2a3555dbf2b38f ... On Linux/X11 even when you run a program sandboxed or as a different user if you use a master Xserver the sandboxed program still can listen and modify all your input/output including keyboard/mouse events and window content of every application.

could xhost(1) help here?

Re: Linux Zoom client proactively reading everything written to X11 clipboard

#106

Post by amelius »

drnick1 wrote: post #58
amelius wrote: post #21

I'm not surprised by news like this anymore. When will Linux distributions properly sandbox our applications? Our phones have had a better permission system for years.

Linux generally presumes that you run trusted software, not some proprietary program that is approximately malware. If you want a "sandbox" run that program as a separate unprivileged user or use bubblewrap.

> Linux generally presumes that you run trusted software, not some proprietary program that is approximately malware.

But this statement basically says: "Linux has no good permission controls for running software". The assumption is flawed. Trusting software is not a true/false thing.

Yes, you can use sandboxing tools, but how many people use them properly? How many usability bugs do they still have?

Re: Linux Zoom client proactively reading everything written to X11 clipboard

#108

Post by shevy-java »

wolfi1 wrote: post #104
rwmj wrote: post #101

Earlier quoted context omitted.

That doesn't change that programs doing this can be shady (or very useful).

but sandboxing would be quite useless

How so? If you can break out of a sandbox then by definition it is not a sandbox.

There are ways to force sandbox jail. For instance, giving processes only a partial view of the computer system. GoboLinux did this years ago via ViewFS (https://linuxphilia.blogspot.com/2009/07/gobolinux-is-linux-... search for ViewFS). There are many other similar solutions, some probably better.

Re: Linux Zoom client proactively reading everything written to X11 clipboard

#109

Post by wolfi1 »

shevy-java wrote: post #108
wolfi1 wrote: post #104

Earlier quoted context omitted.

but sandboxing would be quite useless

How so? If you can break out of a sandbox then by definition it is not a sandbox. There are ways to force sandbox jail. For instance, giving processes only a partial view of the computer system. GoboLinux did this years ago via ViewFS ( https://linuxphilia.blogspot.com/2009/07/gobolinux-is-linux-... search for ViewFS). There are many other similar solutions, some probably better.

X itself is the problem here, not the process attached to
Post reply on HN