I noticed today that an update to the #Linux #Zoom client has made it start proactively reading _everything_ written to the X11 clipboard.
-
I noticed today that an update to the #Linux #Zoom client has made it start proactively reading _everything_ written to the X11 clipboard.
If you keep interesting secrets in your clipboard – particularly, if a password manager uses it as a means of getting the password to where it needs to be – this might be a thing you need to know about!
@simontatham i see, with them also removing features from the browser version and adding a popup saying to use the app i can't see this as anything over than malicious
-
I noticed today that an update to the #Linux #Zoom client has made it start proactively reading _everything_ written to the X11 clipboard.
If you keep interesting secrets in your clipboard – particularly, if a password manager uses it as a means of getting the password to where it needs to be – this might be a thing you need to know about!
@simontatham If I ever have to use Zoom, it's through the browser.
-
I noticed today that an update to the #Linux #Zoom client has made it start proactively reading _everything_ written to the X11 clipboard.
If you keep interesting secrets in your clipboard – particularly, if a password manager uses it as a means of getting the password to where it needs to be – this might be a thing you need to know about!
@simontatham
tool "firejail" may help. not sure though.it is good time to mention such tool, which can limit lot of permissions for program.
-
I noticed today that an update to the #Linux #Zoom client has made it start proactively reading _everything_ written to the X11 clipboard.
If you keep interesting secrets in your clipboard – particularly, if a password manager uses it as a means of getting the password to where it needs to be – this might be a thing you need to know about!
@simontatham That's typical malware behaviour
-
I noticed today that an update to the #Linux #Zoom client has made it start proactively reading _everything_ written to the X11 clipboard.
If you keep interesting secrets in your clipboard – particularly, if a password manager uses it as a means of getting the password to where it needs to be – this might be a thing you need to know about!
@simontatham and let me guess: they didn't say shit about it. "Bug fixes and improvements!!!"
-
I noticed today that an update to the #Linux #Zoom client has made it start proactively reading _everything_ written to the X11 clipboard.
If you keep interesting secrets in your clipboard – particularly, if a password manager uses it as a means of getting the password to where it needs to be – this might be a thing you need to know about!
@simontatham …and I'm the unreasonable one for being somewhat picky about what I install on my machine.
-
@nicksilkey the way the X11 selection mechanism works is that every time an application wants to paste, it contacts the current selection owner and asks it to send the data.
This allows some amusing stunts, like writing a selection client that always pastes the _current_ time, rather than the time the clipboard was (logically speaking) written. But it also means that the selection-owning application _knows_ when someone is pasting from it, and can do things in response.
A one-shot paste tool is a thing that starts up, claims ownership of the clipboard, waits until it's received and fulfilled _one_ paste request, and then immediately terminates.
It so happens that I use one I wrote myself. But others exist. One that's already available in Debian and Ubuntu is 'xclip'. If you do this …
sudo apt install xclip # if you don't have it installed already
echo -n foo | xclip -selection primary -loop 1 -verbose... then middle-clicking in some other window should cause two things to happen. First, it pastes 'foo'. But also, the xclip tool terminates, and your shell prompt comes back in the first terminal.
If you use '-selection clipboard' instead of '-selection primary' then it will write the other clipboard, the one that typically pastes using ^V or similar. Except that if you're running Zoom 7.1.5 on the same X server, it won't wait for you to paste something on purpose – it will terminate immediately, because it already received a paste request from Zoom!
@simontatham @nicksilkey, hmm…
$ echo -n foo | xclip -selection primary -loop 1 -verbose
Loops: 1
Using selection: XA_PRIMARY
Using target: UTF8_STRING.
Waiting for one selection request.
+ Creating new requestor for 'Easy Effects' (0x2600002)
- Deleting requestor for 'Easy Effects' (0x2600002)
$… er, what? Okay, if it were Clipman, that'd be fine (that's expected), but Easy Effects?
(It does this to
XA_CLIPBOARDtoo, but notXA_SECONDARY. Running 7.2.3; I don't know if 8.x does this.) -
@simontatham@hachyderm.io
Does this affect Zoom Web?@2something@transfem.social @simontatham@hachyderm.io probably not, afaik there's no way for a web page to read the clipboard without being granted permission https://developer.mozilla.org/en-US/docs/Web/API/Clipboard_API#security_considerations
-
I noticed today that an update to the #Linux #Zoom client has made it start proactively reading _everything_ written to the X11 clipboard.
If you keep interesting secrets in your clipboard – particularly, if a password manager uses it as a means of getting the password to where it needs to be – this might be a thing you need to know about!
@simontatham Two solutions I've used, when I have to use Zoom:
1. Use the Zoom Web site. The Web page for the call first makes you try to open the desktop client, but when that fails, a small option appears on the Web page, to do it using Web standards.
2. Dedicated device for Zoom. At an anti-counterfeit-goods startup, after Zoom was sending US calls through CN, seemed prudent to isolate Zoom from eng and ops laptops. I got an iPad, to isolate easier than a dedicated Linux box for Zoom.
-
@simontatham for cases like that, there are often external data control protocols used to make it work. because it’s easy to inspect what clients use what protocols, you can make sure only a client you trust uses those protocols. standard clients don’t tend to use them though, generally only clipboard related utilities and the like
@shrub900 @simontatham Yes, compositors can have policy to allow exceptions, particularly for things like wl-clipboard and whatnot. But standard clients *generally* don't have the ability to do this in most desktops (though I think some freestanding WMs don't restrict this by default).
-
I noticed today that an update to the #Linux #Zoom client has made it start proactively reading _everything_ written to the X11 clipboard.
If you keep interesting secrets in your clipboard – particularly, if a password manager uses it as a means of getting the password to where it needs to be – this might be a thing you need to know about!
@simontatham It would be interesting to know what Zoom actually does with the captured clipboard content.
-
S simonjust@mstdn.dk shared this topic
