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!
Some details:
This is Linux Zoom 7.1.5. Previously I had 6.6 installed, which didn't do this.
It appears to only care about the CLIPBOARD selection – the one with Windows-ish UX, which you typically copy to explicitly with a keystroke such as ^C, and paste from with ^V (or similar). It doesn't look at PRIMARY, the selection used for trad X11 "just select in this window then middle-click in the other" copy-paste.
It looks as if it's detecting changes of clipboard via the XFIXES extension, and whenever the clipboard is claimed by a new owner, it immediately sends that client a paste request.
I noticed it because I make heavy use of a "one-shot paste" tool which fulfills a single paste request and then terminates. Handy for filling in lots of fields of a web form – queue up pastes of several different things, then go to each form field in turn and just hit paste, bam bam bam. But today, after an apt update, it doesn't work: my one-shot paste tool terminates as soon as it starts, because (I found out after some debugging) Zoom always requests a paste immediately.
(Regular readers might recall that around this time _last_ year I caught Slack doing something similar, but only when focus entered the Slack window, and also, they had a configuration option to turn it off. A one-shot paste tool seems to be a good way to notice weird things going on in the X server!)
-
Some details:
This is Linux Zoom 7.1.5. Previously I had 6.6 installed, which didn't do this.
It appears to only care about the CLIPBOARD selection – the one with Windows-ish UX, which you typically copy to explicitly with a keystroke such as ^C, and paste from with ^V (or similar). It doesn't look at PRIMARY, the selection used for trad X11 "just select in this window then middle-click in the other" copy-paste.
It looks as if it's detecting changes of clipboard via the XFIXES extension, and whenever the clipboard is claimed by a new owner, it immediately sends that client a paste request.
I noticed it because I make heavy use of a "one-shot paste" tool which fulfills a single paste request and then terminates. Handy for filling in lots of fields of a web form – queue up pastes of several different things, then go to each form field in turn and just hit paste, bam bam bam. But today, after an apt update, it doesn't work: my one-shot paste tool terminates as soon as it starts, because (I found out after some debugging) Zoom always requests a paste immediately.
(Regular readers might recall that around this time _last_ year I caught Slack doing something similar, but only when focus entered the Slack window, and also, they had a configuration option to turn it off. A one-shot paste tool seems to be a good way to notice weird things going on in the X server!)
@simontatham
Packaged Zoom or sandboxed/flatpak? -
@simontatham
Packaged Zoom or sandboxed/flatpak?@Brett_E_Carlock good point, I should have specified that. It's the .deb package.
-
Some details:
This is Linux Zoom 7.1.5. Previously I had 6.6 installed, which didn't do this.
It appears to only care about the CLIPBOARD selection – the one with Windows-ish UX, which you typically copy to explicitly with a keystroke such as ^C, and paste from with ^V (or similar). It doesn't look at PRIMARY, the selection used for trad X11 "just select in this window then middle-click in the other" copy-paste.
It looks as if it's detecting changes of clipboard via the XFIXES extension, and whenever the clipboard is claimed by a new owner, it immediately sends that client a paste request.
I noticed it because I make heavy use of a "one-shot paste" tool which fulfills a single paste request and then terminates. Handy for filling in lots of fields of a web form – queue up pastes of several different things, then go to each form field in turn and just hit paste, bam bam bam. But today, after an apt update, it doesn't work: my one-shot paste tool terminates as soon as it starts, because (I found out after some debugging) Zoom always requests a paste immediately.
(Regular readers might recall that around this time _last_ year I caught Slack doing something similar, but only when focus entered the Slack window, and also, they had a configuration option to turn it off. A one-shot paste tool seems to be a good way to notice weird things going on in the X server!)
@simontatham thanks for this write up! 🫂
Q: what's a one shot paste tool?
-
@simontatham thanks for this write up! 🫂
Q: what's a one shot paste tool?
@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!
-
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 wayland fixes this
-
@simontatham wayland fixes this
@shrub900 can you say how? I've never got round to learning Wayland. What restrictions can it place on clipboard use that prevent this kind of unwanted behaviour while still allowing intentional copy-paste?
-
Some details:
This is Linux Zoom 7.1.5. Previously I had 6.6 installed, which didn't do this.
It appears to only care about the CLIPBOARD selection – the one with Windows-ish UX, which you typically copy to explicitly with a keystroke such as ^C, and paste from with ^V (or similar). It doesn't look at PRIMARY, the selection used for trad X11 "just select in this window then middle-click in the other" copy-paste.
It looks as if it's detecting changes of clipboard via the XFIXES extension, and whenever the clipboard is claimed by a new owner, it immediately sends that client a paste request.
I noticed it because I make heavy use of a "one-shot paste" tool which fulfills a single paste request and then terminates. Handy for filling in lots of fields of a web form – queue up pastes of several different things, then go to each form field in turn and just hit paste, bam bam bam. But today, after an apt update, it doesn't work: my one-shot paste tool terminates as soon as it starts, because (I found out after some debugging) Zoom always requests a paste immediately.
(Regular readers might recall that around this time _last_ year I caught Slack doing something similar, but only when focus entered the Slack window, and also, they had a configuration option to turn it off. A one-shot paste tool seems to be a good way to notice weird things going on in the X server!)
@simontatham they have also changed the zoom client to always be running in the background. That's it for me, will avoid.
-
@shrub900 can you say how? I've never got round to learning Wayland. What restrictions can it place on clipboard use that prevent this kind of unwanted behaviour while still allowing intentional copy-paste?
@simontatham generally on wayland only applications with keyboard focus can get access to the clipboard, which would prevent zoom from getting the clipboard content when it’s running in the background.
-
@shrub900 can you say how? I've never got round to learning Wayland. What restrictions can it place on clipboard use that prevent this kind of unwanted behaviour while still allowing intentional copy-paste?
@simontatham@hachyderm.io @shrub900@mastodon.social for one the program has to explicitly pass in an input event that triggered the paste action (and the compositor can decide to for example say that mouse movement isn't valid for that)
-
@simontatham generally on wayland only applications with keyboard focus can get access to the clipboard, which would prevent zoom from getting the clipboard content when it’s running in the background.
@shrub900 I see, thanks. So a side effect would be that command-line pasting tools, like 'xclip -o', also couldn't work?
That's quite a big tradeoff for some users – me in particular. I use that kind of workflow a lot. As and when I move towards Wayland, I'll have to work out what to do about losing that.
-
@shrub900 I see, thanks. So a side effect would be that command-line pasting tools, like 'xclip -o', also couldn't work?
That's quite a big tradeoff for some users – me in particular. I use that kind of workflow a lot. As and when I move towards Wayland, I'll have to work out what to do about losing that.
@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
-
Some details:
This is Linux Zoom 7.1.5. Previously I had 6.6 installed, which didn't do this.
It appears to only care about the CLIPBOARD selection – the one with Windows-ish UX, which you typically copy to explicitly with a keystroke such as ^C, and paste from with ^V (or similar). It doesn't look at PRIMARY, the selection used for trad X11 "just select in this window then middle-click in the other" copy-paste.
It looks as if it's detecting changes of clipboard via the XFIXES extension, and whenever the clipboard is claimed by a new owner, it immediately sends that client a paste request.
I noticed it because I make heavy use of a "one-shot paste" tool which fulfills a single paste request and then terminates. Handy for filling in lots of fields of a web form – queue up pastes of several different things, then go to each form field in turn and just hit paste, bam bam bam. But today, after an apt update, it doesn't work: my one-shot paste tool terminates as soon as it starts, because (I found out after some debugging) Zoom always requests a paste immediately.
(Regular readers might recall that around this time _last_ year I caught Slack doing something similar, but only when focus entered the Slack window, and also, they had a configuration option to turn it off. A one-shot paste tool seems to be a good way to notice weird things going on in the X server!)
@simontatham what did it do when you put a large hex number in the 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
TL;DR: Zoom is now a password stealer.Glad I mostly use autotype, rather than clipboard. Also, I believe many password managers can do one shot paste, to prevent accidentally pasting your password in the wrong window. Which would not prevent this, but would have caught it.
-
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 ah yes, zoom who, last i used it some years ago, ran a C compiler in the background every 10s. I am very surprised they are, once again, doing crazy shit
-
@simontatham ah yes, zoom who, last i used it some years ago, ran a C compiler in the background every 10s. I am very surprised they are, once again, doing crazy shit
@kamstrup @simontatham Back in the days, like at the end of the last decade Zoom also ran a web server which opened a port wide open so users would not need to press a button.
I guess there is certain kind of work culture in the house.
-
@glent that sounds like a very plausible thing to try, but I can't find that setting!
In the Zoom client's Settings dialog box, the "My account" entry in the left sidebar only offers me some links to the web version of my account settings, an option to make a voice recording for smart voice recognition, and a list of all the clients logged in to my account.
Other plausible sidebar entries, like "Meetings & webinars" or "Share screen", don't have any option of that kind either.
Searching for 'clipboard' in the whole settings box, via the search tool at the top of the left sidebar, only finds "Automatically copy invite link to clipboard" in the Meetings tab.
-
@glent ah, yes, now I see that in the web version of Settings it's there, a long way down a very large page.
But no luck, I'm afraid. I turned that off; pressed Save; quit and restarted the local Zoom client, since you said the web settings might only be loaded at startup; and alas, the unwanted clipboard slurping is still happening.
-
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!
that sounds like a security nightmare.
-
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@hachyderm.io
Does this affect Zoom Web?
