16 ms·

Who keeps an eye on clipboard access?

258 points by pndy 5y ago

root5 5y ago
As iOS and macOS share their clipboard over BLE, one can abuse this feature for various things like smart home automation. https://twitter.com/m33x/status/1489236070151737351 https://twitter.com/m33x/status/1489236070151737351
- pierrefermat1 5y ago
  If I read the tweets correctly this is only capable of capturing the event happening and not the content? I don't see this too much of a privacy issue
alexvoda 5y ago
To what degree does Wayland solve this compared to X?
- jchw 5y ago
  I believe in Wayland, only foreground applications can access the clipboard. I can’t recall how poorly XWayland fares; I suspect it just bypasses the security boundary. Nonetheless, still useful, especially e.g. for sandboxed apps. I don’t think clients can, without extensions, watch for who’s snooping the clipboard. However… it probably wouldn’t be difficult to integrate this into the compositor. You could even imagine a Wayland protocol for watching clipboard accesses, or god forbid, a dbus service for doing so.
  - Arnavion 5y ago
    >I believe in Wayland, only foreground applications can access the clipboard. To be precise, Wayland does not care who or what accesses the clipboard. Whether or not only foreground applications can access the clipboard is determined by which clients the particular compositor sends wl_data_offer events to. So the answer to alexvoda's question is: Wayland doesn't solve the problem completely. wl_data_offer events are pushed from the compositor to the client rather than the client asking for a data offer. The compositor cannot know whether the client may want the data offer, so it has to send the event to every client regardless of whether the client ends up needing it or not. For most (if not all) compositors today, "every client" means "clients that are currently focused", so while a background application can't snoop your clipboard, simply focusing such an application would allow it to snoop. Furthermore, extensions like wlr-data-control are specifically designed for background snooping, since they're intended to be used by clipboard managers. It's again up to the compositor to apply security to this, like only allowing a single specific process to be the data control manager and not arbitrary programs. For wlr-data-control I'm not aware of any compositor that applies such a policy; it would, at the very least, break `wl-paste`.
  - emersion 5y ago
    XWayland as a whole is itself a Wayland client. So as long as any X11 window has focus then any other X11 window can steal the clipboard. But once a Wayland window is focused, X11 windows don't have access anymore.
tiku 5y ago
I have removed the LinkedIn and Twitter app because they force directed the website to the app, but good to know that it could also see my clipboard and even track it perhaps..
rcthompson 5y ago
On recent Android versions you get a pop-up notification whenever an app accesses the clipboard. (I think it doesn't notify for the active app, or maybe it doesn't notify for explicit user-initiated clipboard interactions, I'm not sure exactly what the rules are.) If I saw any app repeatedly accessing the clipboard for no discernible reason, I would definitely uninstall it.
- jeroenhd 5y ago
  Android killed background clipboard access in an Android update entirely, except for system and vendor applications. I had to root my phone to get clipboard sync working again in KDE connect. I haven't seen the notification myself, but I'm still on Android 11. From what I can tell for user-installed applications, only the active application and the keyboard get clipboard access, regardless of permissions and capabilities declared in the app manifest. I get why they did this but I think it's a bad choice not to allow the user to opt into clipboard management. Going back to manually typing TOTP codes was more annoying than rooting my phone.
  - Hallucinaut 5y ago
    I have a Pixel 6 and I've noticed an app from some Wi-fi lights with an app called TCP Smart copies my clipboard whenever I open it. I was disturbed by this and definitely didn't do anything special to permit it, so that seems somewhat at odds with what you're saying?
    - jeroenhd 5y ago
      Perhaps I misinterpreted; you're right. Foreground apps are perfectly allowed to use the clipboard, it's just background app access that got axed. Apps don't even need any permissions to respond to clipboard events! The toasts were added to Android 12 (https://developer.android.com/about/versions/12/behavior-changes-all#clipboard-access-notifications https://developer.android.com/about/versions/12/behavior-cha...) but the permission required to call from the background isn't available to normal apps. The API should only show for active applications or input methods, and non-IME inputs that call the API (i.e. foreground apps) will show a notification if you have this setting enabled. Basically, it should only happen with the TCP Smart app open, and show when the TCP Smart app is using the clipboard. It shouldn't just randomly happen inside other apps, unless the devs behind that app are somehow bypassing Android's security features.
throwntoday 5y ago
iOS/macOS really need to add clipboard to privacy settings. I opened monopoly on iOS and the first thing it did was paste my clipboard to god knows where.
bagels 5y ago
Why can apps even read it in the first place, as opposed to the os sending it only to apps the user initiates a paste in?
- kukx 5y ago
  It can be useful of you want to use a non standard way to paste stuff, example a right mouse button in putty.
- jchw 5y ago
  IMO: you have to look at how OSes and window systems were designed and evolved to get a great answer here. Those processes resulted in systems where the OS or compositor or window system itself can’t really know when the user is pasting something or not. It could be changed, but it would have lots of implications globally, from rewriting framework code, to changing JS APIs. Edge cases would be handled worse, like non-standard paste gestures or VM integration.
- kelnos 5y ago
  Because the OS doesn't know when the user initiates a paste. The user tells an application that they want to paste, and then the application tells the OS to give it the contents of the clipboard. (Sort of; some windowing systems do it slightly differently, but that's the gist of it.) That's indistinguishable from the application telling the OS it wants to paste when the user hasn't requested it. Sure, there are ways that you could design the system, such as making it so the only way to paste is for the user to hit a key combination, or perhaps click on or touch a UI element that is known to be controlled/hosted/owned by the OS. Then the OS can push the clipboard contents to the foreground application, rather than the application trying to pull it. But then that becomes very limiting, UX-wise. (For example, you wouldn't be able to put a "paste" item in a context menu.) You could also have a permissions model, where the OS prompts for permission every time an app wants to fetch the clipboard contents (presumably with an "I trust this app" option to get it to stop asking). But that might be considered too intrusive, or possibly just ineffective, as people will often just mash at whatever button is closest to get a modal dialog to go away. At any rate, we have these copy/paste mechanisms from when people didn't really think about local security in the way we do today. Redesigning things would break a lot of existing applications. It might be worth it, or it might not.
rank0 5y ago
Is it possible to deny clipboard access to every application and only pass the info through stdin through the explicit ctrl-v or pbpaste/xclip/whatever?
- fsflover 5y ago
  Yes, on Qubes OS, https://qubes-os.org https://qubes-os.org. It's based on VMs for secure and transparent compartmentalization.
  - rank0 5y ago
    I am familiar with Qubes, but I'm asking if this specific security control could be used elsewhere.
tlarkworthy 5y ago
I have taken to copying a benign string after using a sensitive password and I minimize switching tabs during transport of said password.
- Gare 5y ago
  Some password management programs (I know for KeePassXC) clear the clipboard automatically after several seconds.
  - mackatap 5y ago
    Bitwarden does as well, though it seems more like 20-30 seconds.
    - gnabgib 5y ago
      It doesn't by default (perhaps it depends on which version you first installed) but it is available under File -> Settings -> Options: Clear Clipboard which can e set to never/10s/20s/30s/1m/2m/5m.
  - SubiculumCode 5y ago
    This is good to know, but it still doesn't help if there is an application phone app, etc, that monitors the clipboard.
- npteljes 5y ago
  That's a good practice. KeePass 2, KeePassX and KeePassXC, and KeePassDX on Android do this by default as well. It's even better to use the Auto-Type feature of these software, because then the password never gets on the clipboard in the first place.
ZeroGravitas 5y ago
This is part of the reason I don't set Vim to automatically fill the system clipboard and only do so on demand. I think a few other geeky apps let you cut and paste internally as a separate thing from the global clipboard, which seems wise as a mitigation.
adrium 5y ago
Does it really come as a surprise that apps are exploiting the clipboard? TLDR: Drag and drop sensitive stuff. If necessary, copy only part of sensitive information, enter the rest manually. The amount of usability obstacles in the name of security is getting ridiculous. For example, when I got a new company mac, I had to enter my keychain access password and grant access to folders countless times - and I still have to do that after one week of using it occasionally. Similarly annoying are the cookie questions. In the beginning, I found it interesting and tried to reduce the number of cookies as much as possible - now I just click what ever button brings me to the site fastest (or don't click a button at all, if it is still possible to scroll and see about half of the page on mobile). Don't you also feel some kind of fatigue? Now please do not cripple the clipboard the same way. By the way: Qubes OS takes an interesting approach here. Similar to suggestions by some of the commenters. [1] Don't get me wrong: I am extremely sensible to security - but also to usability. I want to use my daily-driver system conveniently and it should "just work" and I want to trust it fully [2]. I do not just install any trash app, simply because there is one available. On the desktop: 1. Only applications from the official repos get installed. I may install other open source software occasionally. So yes, the trust lies with the distro. 2. Other software (potentially untrusted or good to be isolated) like banking or tax software or zoom get a proot environment or a new user profile. 3. Most software can be run in the browser anyway and it is actually quite a nice sandboxing tech. Web apps can not simply read the clipboard. [3] 4. Clear cookies on browser exit. I have a whitelist for about two or three sites to keep the state for convenience. 5. Browser extension that manages and fills passwords on request(!). No need to copy-paste around. [4] 6. If I need passwords elsewhere, I use drag and drop. I believe this is extremely convenient and very secure. That works 90% of the time, otherwise, I copy only part of the sensitive information and enter the rest manually. On mobile: 1. Same goes for app installation: open-source only from F-Droid. 2. Other apps get put in a work profile and disabled when not used. [5] No trash like games and social media. 3. Do not copy paste sensitive information, but use IME apps (keyboard apps that actually "type" passwords). Personally, I like KeePassDX and sometimes use KDE Connect. [6] Accounts: 1. I own several domains and mobile numbers, all companies that want my info get different data. 2. Fill in bogus information if possible. I may have gone overboard with this :-D But I don't even care about MFA that much at this point... And it is an interesting experiment to see what company leaks data. [1] https://www.qubes-os.org/doc/how-to-copy-and-paste-text/ https://www.qubes-os.org/doc/how-to-copy-and-paste-text/ [2] Kubuntu fanboy here and Android still on version 8 though because of ROM customization [3] https://developer.mozilla.org/en-US/docs/Web/API/Clipboard/read https://developer.mozilla.org/en-US/docs/Web/API/Clipboard/r... [4] https://github.com/adrium/easypass https://github.com/adrium/easypass [5] https://f-droid.org/en/packages/net.typeblog.shelter/ https://f-droid.org/en/packages/net.typeblog.shelter/ [6] https://www.keepassdx.com/ https://www.keepassdx.com/ and https://f-droid.org/en/packages/org.kde.kdeconnect_tp/ https://f-droid.org/en/packages/org.kde.kdeconnect_tp/ And I wrote a KeePass plugin to convert the passwords: https://github.com/adrium/KeepassPfpConverter https://github.com/adrium/KeepassPfpConverter
photon12 5y ago
The Qubes clipboard model is one of the reasons I use that OS: https://www.qubes-os.org/doc/how-to-copy-and-paste-text/ https://www.qubes-os.org/doc/how-to-copy-and-paste-text/
alkonaut 5y ago
That my web browser process can read my windows clipboard is fine, what’s important is that it prevents the web pages it has loaded from doing the same. I can’t trust all web pages but trusting all my desktop programs is a much easier pill to swallow. Windows could certainly tighten the security by optionally only allowing foreground/focused apps to access, or notifying the user when apps read the clipboard without being in focus or sent any input first.
- badsectoracula 5y ago
  > Windows could certainly tighten the security by optionally only allowing foreground/focused apps to access That would break clipboard managers which are very useful tools to have in various occasions. E.g. in a previous job i worked at, some audio designers used a clipboard manager to quickly fill settings in various tool fields. Fun fact: most clipboard managers tend to use global shortcut keys for cycling through the recent N copies (or for pasting specifically tagged content, e.g. copy something and mark it to be used for pasting after Shift+Alt+1 is hit, same for Shift+Alt+2 for something else, etc), which is another thing that you'd hear security concerns for :-P
  - nsgi 5y ago
    Sure, but that should really be a permission you have to grant explicitly. For global keyboard shortcuts an app should make commands available and it should be up to the user to tell their OS which shortcuts they want to give an app. Not just for security, but also for customisability and to avoid conflicts
    - badsectoracula 5y ago
      > Sure, but that should really be a permission you have to grant explicitly. That could work but still feels dodgy since if you can grant that permission to a clipboard manager, you can also grant it to something like a TikTok client or an Adobe DRM reader or whatever else program you want to use (ie. the reason you are using your computer in the first place) but also might want to snoop for your data. IMO a better solution that wouldn't break existing clipboard usage is to have a second "secure" clipboard that you can lock as tight as you want with explicit permissions for reading it, notifications for writing to it and whatever else you want. Then password managers would copy data to that and text editors and browsers can have a "Copy Sensitive Data" (or something better worded) in addition to "Copy" that will place data there. Sure some people will still use Copy but some people will also stick post-it notes with their passwords on their monitors and give thousands of dollars to Nigerian princes - you shouldn't to punish everyone for the ignorance of a few. > For global keyboard shortcuts an app should make commands available and it should be up to the user to tell their OS which shortcuts they want to give an app. Not just for security, but also for customisability and to avoid conflicts This only works if all applications are using the same framework and toolkit and target the same OS. Meanwhile notice how even when you limit yourself to applications targeting Windows alone there are tons of different frameworks - let alone cross platform applications that tend to use a lowest common denominator approach. IMO if you want to get more secure functionality, you need to do it in a way that works alongside existing practice - hence containers and sandboxing for untrusted applications working alongside trusted applications that can do what they want. Unless you start everything from scratch on a brand new computing approach (like mobiles did and even then it barely works and despite people treating mobiles almost like consumables), trying to force a top-down approach to security is doomed to fail.
beermonster 5y ago
Is there a Little Snitch/open snitch/Lulu type tool for Clipboard access?
- dethos 5y ago
  As far as I'm aware, there isn't. And it would be a nice tool to have available, I suspect this could be integrated into existing clipboard managers.
DavideNL 5y ago
Related tool for macOS: https://langui.net/clear-clipboard/ https://langui.net/clear-clipboard/ Clear Clipboard allows you to clear the clipboard content manually or automatically, preventing your clipboard data from being peeped while you are absent. You can chose to clear the clipboard content every few seconds and enable clearing clipboard on computer sleep / display sleep / screen lock to maximize protection of your sensitive clipboard data.
- nigwil_ 5y ago
  Could use Automator with AppleScript: x@Mac-mini-M1 ~ % cat ClearClipboard.scpt on run tell application "System Events" to set the clipboard to "" end run x@Mac-mini-M1 ~ %
CyberShadow 5y ago
Currently writing a clipboard manager[1], I've seen some things as well. - So far ran into two applications which don't even implement the X11 clipboard specification (ICCCM section 2) correctly - xsel and Emacs (patches submitted). - By far the worst offense I've seen in clipboard privacy on the Linux desktop is RedHat's virt-manager. It sends your clipboard AND selection content to all virtual machines, even when they are not focused, with no indication that it's happening, and with no GUI option to turn it off. This is at odds with the common practice of running untrusted code in virtual machines. - X11 being network-transparent makes its protocol fairly malleable, so it's not difficult to bolt some privacy on top. hax11[2] has an option to restrict access to the primary selection for configured applications (though, for truly malicious applications, you may find X11's security model generally lacking). [1]: https://news.ycombinator.com/item?id=29808487 https://news.ycombinator.com/item?id=29808487 [2]: https://github.com/CyberShadow/hax11 https://github.com/CyberShadow/hax11
- thrwawy283 5y ago
  I've always wanted an application dedicated to managing the clipboard. It would provide security and even offer interchange conversion that existing apps do not implement. For example: Copying HTML in Windows it has an associated mime type that receiving applications can recognize and choose to convert from. I've always wanted a clipboard/paste manager - with history - like this, that would allow me to copy, manipulate, and paste or share that data to another application. I don't know how this would look, but even the ability to pop open my paste manager and look at the copied contents, filter it, or split the text, or (silly stuff) convert text to emoji'fied content, or take a screenshot of that (text to bitmap), and create a new entry within the paste manager. For some of my friends it would be awesome to have a hex editor in there. Perhaps there are 2 focuses: Isolating what is copied from applications until the user chooses to expose it, and the history function. Being able to send it to another app for manipulation and pulling it back is a 2nd responsibility. It would be /suave/ to have this all in the same GUI brought up by the compositor, though.
  - 1vuio0pswjnm7 5y ago
    https://f-droid.org/en/packages/org.dslul.openboard.inputmethod.latin/ https://f-droid.org/en/packages/org.dslul.openboard.inputmet... This replacement keyboard for Android saves clips and allows the user to select and paste them into any application. Most importantly, it allows the user to delete the contents of the clipboard. It also allows the user to "pin" certain clips to be retained for future pasting. Clip storage. If one needs a further reason to replace the keyboard, consider that the default keyboard on Google phones, Gboard, tries to phone home to Google. A keyboard that expects internet access. Incredible.
octavqq 5y ago
hehehe
AshamedCaptain 5y ago
> it seems that due to the nature of X11 it is not possible to know which running process owns the window that is accessing the clipboard. A shame. You definitely can. Search for _NET_WM_PID. Now this being X11, this is again just a convention, and a client could put any information it wants in that property. > While very useful, this raises a lot of security questions. Really, it doesn't. If these programs want to share information, they already can. If these programs want to spy on each other's memory contents, they already can. Unless you are running these programs as different users and with different home directories, which is not usual right now in desktop GNU/Linux (but is on Android).
- dethos 5y ago
  > You definitely can. Search for _NET_WM_PID. Now this being X11, this is again just a convention, and a client could put any information it wants in that property. That was the reason I mentioned that "it is not possible to know", perhaps "for sure" is missing at the end of the sentence. > Really, it doesn't. As a user (at least in my opinion) it does. > If these programs want to share information, they already can. If these programs want to spy on each other's memory contents, they already can. Unless you are running these programs as different users and with different home directories, which is not usual right now in desktop GNU/Linux (but is on Android). The point is, when the user copies a piece of information he has a clear target for that information (clipboard is the tool he uses do copy from one window to another), why would all other apps have access to it? It is the user that wants to share information not the apps. Even taking account all those capabilities, many pieces of malware rely on detecting and replacing information on the clipboard, that is a clear indication that some sort of isolation is missing here, or at least, and indication regarding that the information was changed/accessed.
  - AshamedCaptain 5y ago
    > The point is, when the user copies a piece of information he has a clear target for that information (clipboard is the tool he uses do copy from one window to another), why would all other apps have access to it? Everything that is run by the user runs in the same context. There is little point in focusing on the clipboard, because any two programs running within the same user can do literally anything to each other. Including spying on each other keystrokes, modifying each other's text widgets contents, and faking whatever text/images they are displaying. The fact that they may alter the clipboard contents is irrelevant when they can literally monitor and inject keystrokes on each other. This is the security model that we have right now at the desktop. Good luck trying to find a better one that just does not completely break UNIX and turns it into something like Android. One of the benefit of this model is that you (the user) have practically unlimited freedom in hooking the system in ways that nobody expects (e.g. a clipboard access detector), but then so does anybody else you decide to trust (by running their program in the same context).
abaines 5y ago
With most installations of X11 / Xlib, there is also an extension library: libXFixes. With this, it is possible to receive an event whenever the clipboard (or any other selection) changes (even if our program is not the owner). [0] I used this in the past when porting a Windows text editor to Linux that needed to know when the clipboard had changed. In the C bindings, it corresponds to XFixesSetSelectionOwnerNotifyMask / XFixesSelectionNotifyEvent. There is also a SelectionNotify event in the core X11 protocol, but I'm pretty sure it is different (occurs in response to XConvertSelection - asking for the clipboard contents). Though it has been some time since I wrote the code I'm looking at. [0]: https://www.x.org/releases/current/doc/fixesproto/fixesproto.txt https://www.x.org/releases/current/doc/fixesproto/fixesproto... (6. Selection Tracking)
- CyberShadow 5y ago
  I think the goal here is to be notified when an application accesses the clipboard, not modifies it. You need to be the owner to do that (excluding some system-wide hack like patching the X server or MITM-ing all X11 connections).
c0l0 5y ago
I think Linux dynamic user probes would lend themselves quite well for something like this. Fooling around with bpftrace for a few minutes yielded this one-liner, which catches all the conscious X11 selection accesses (and a few unconscious ones, too :)) I provoked on my desktop during a few minutes of testing: sudo bpftrace -e 'uprobe:/usr/lib/libX11.so:XGetSelectionOwner{time("%H:%M:%S ");printf("%-6d\n", pid);}' I am not familiar with Xlib/X11 at all, so I am not sure which library functions one would be most interested in to explore this much further. Edit: Replaced `XSetSelectionOwner` with `XGetSelectionOwner` in bpftrace invocation.
- CyberShadow 5y ago
  I am not familiar with bpftrace (though that does look extremely potent), but XSetSelectionOwner is called when an application wants to make data available via the clipboard, not access it. Also not sure if that would also catch stuff with Xlib, and I guess it won't if it's statically linked (this is why I pivoted hax11 from hooking library calls to MITM-ing the connection).
  - c0l0 5y ago
    My bad, I actually had the "production" trace command set to look for `XGetSelectionOwner`, but mis-pasted into my comment ;) Will that fare any better? It did make a few more PIDs/culprits end up in the trace output for me after all. You are correct that "bringing your own function"/shared object will break that particular bpftrace script, but I would assume one could find a way to set up a probe in the X server, where all clients messing with clipboard state via some kind of IPC have to pass thru? (Again, I can only wildly speculate how X11 works under the hood - kinda shameful that I never bothered to look over all these years :-S )
    - CyberShadow 5y ago
      I think XConvertSelection would be more effective. Applications which use the XFixes extension to receive notifications of new owners won't need to use XGetSelectionOwner.
backtoyoujim 5y ago
Then what watches the clipboard watcher ?
- dolmen 5y ago
  The user.
anderspitman 5y ago
I've been thinking it would be fun to make a self-hosted web clipboard that lets you paste text/files into a simple web page, and have them available on all your devices. Sort of like cl1p.net but e2ee and it would maintain history. You wouldn't need an account because your password could be hashed to yield a unique URL. Only reason I haven't hacked it together already is because I don't trust myself to get the crypto right yet. Anyone aware of something like this already existing?
- Damogran6 5y ago
  I had thought about something similar, only with publishable subscriuptions so N people could share the same clipboard. Only I wanted the opposite: It would be ephemeral, only as long as you subscribed to the ‘feed’ would you see what was there, there would be no history, and pragmatically, no long term retention in the cloud…mostly as a cost savings measure. I got so far as thinking you’d have two guids: One to subscribe to, and the other to revoke the feed. It never got past the thought stage…and I made a logo and registered a URL that I’ve since let expire as the coding took longer than my attention span.
  - tomerv 5y ago
    You're just a few steps away from reinventing Twitter!
juglans 5y ago
Bit Warden password manager app for Linux desktop has an option to clear the clipboard: file -> settings [options]'clear clipboard': dropdown select range from 10 seconds to 5 mins or never. Set & forget.
- opan 5y ago
  KeePassXC does this as well. Even if just copying the username.
phkahler 5y ago
It would make sense to sniff clipbaod paste commands and offer the active app a one time read access for each user provided interaction. Not sure about the value of requiring the same for writes, but it wouldn't hurt. Any time an unauthorized read is attempted the user could be informed. Not sure where this would get plumbed in. Needs support at the toolkit level (menu->edit->paste) and some higher level outside apps. The idea is to obey the users implicit concent and flag everything else.
jonnypotty 5y ago
I used to support a terminal services/citrix environment and we had repeated instances of people trying to copy and paste data and getting other peoples data. Never got anywhere investigating and boss refused to go to Microsoft. I'd forgotten about it till I read this.
Jenda_ 5y ago
At least, I have a script that runs every minute, and if the clipboard contents has not changed, it flushes it. This really helps in preventing accidental paste of sensitive stuff that remained in the clipboard. I also have script that strips newlines (so I can relatively safely paste into terminal without executing anything) and formatting (so I can paste into WYSIWYG editors). All of this is done by simple xclip -out | ... | xclip -in. There was a bug in stardict: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=806960 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=806960 - if you selected something (i.e., copied to clipboard), it tried to look it up in a dictionary and display a translation (by default, just after startup) - online dictionaries, including one available only over HTTP, were enabled by default - so if you used a password manager that copies passwords into clipboard, they were immediately sent in an unencrypted request for the whole world to see We desperately need an application firewall (something like OpenSnitch, but that's so difficult to configure correctly) and basic app isolation (like QubesOS, but that's heavy and pain to use) for Linux. It's a shame that most other OSes, despite having other problems, implement this correctly.

258 points by pndy 5y ago

As iOS and macOS share their clipboard over BLE, one can abuse this feature for various things like smart home automation. https://twitter.com/m33x/status/1489236070151737351 https://twitter.com/m33x/status/1489236070151737351

pierrefermat1 5y ago
If I read the tweets correctly this is only capable of capturing the event happening and not the content? I don't see this too much of a privacy issue

alexvoda 5y ago

To what degree does Wayland solve this compared to X?

jchw 5y ago
I believe in Wayland, only foreground applications can access the clipboard. I can’t recall how poorly XWayland fares; I suspect it just bypasses the security boundary. Nonetheless, still useful, especially e.g. for sandboxed apps. I don’t think clients can, without extensions, watch for who’s snooping the clipboard. However… it probably wouldn’t be difficult to integrate this into the compositor. You could even imagine a Wayland protocol for watching clipboard accesses, or god forbid, a dbus service for doing so.
- Arnavion 5y ago
  >I believe in Wayland, only foreground applications can access the clipboard. To be precise, Wayland does not care who or what accesses the clipboard. Whether or not only foreground applications can access the clipboard is determined by which clients the particular compositor sends wl_data_offer events to. So the answer to alexvoda's question is: Wayland doesn't solve the problem completely. wl_data_offer events are pushed from the compositor to the client rather than the client asking for a data offer. The compositor cannot know whether the client may want the data offer, so it has to send the event to every client regardless of whether the client ends up needing it or not. For most (if not all) compositors today, "every client" means "clients that are currently focused", so while a background application can't snoop your clipboard, simply focusing such an application would allow it to snoop. Furthermore, extensions like wlr-data-control are specifically designed for background snooping, since they're intended to be used by clipboard managers. It's again up to the compositor to apply security to this, like only allowing a single specific process to be the data control manager and not arbitrary programs. For wlr-data-control I'm not aware of any compositor that applies such a policy; it would, at the very least, break `wl-paste`.
- emersion 5y ago
  XWayland as a whole is itself a Wayland client. So as long as any X11 window has focus then any other X11 window can steal the clipboard. But once a Wayland window is focused, X11 windows don't have access anymore.

tiku 5y ago

I have removed the LinkedIn and Twitter app because they force directed the website to the app, but good to know that it could also see my clipboard and even track it perhaps..

rcthompson 5y ago

On recent Android versions you get a pop-up notification whenever an app accesses the clipboard. (I think it doesn't notify for the active app, or maybe it doesn't notify for explicit user-initiated clipboard interactions, I'm not sure exactly what the rules are.) If I saw any app repeatedly accessing the clipboard for no discernible reason, I would definitely uninstall it.

jeroenhd 5y ago
Android killed background clipboard access in an Android update entirely, except for system and vendor applications. I had to root my phone to get clipboard sync working again in KDE connect. I haven't seen the notification myself, but I'm still on Android 11. From what I can tell for user-installed applications, only the active application and the keyboard get clipboard access, regardless of permissions and capabilities declared in the app manifest. I get why they did this but I think it's a bad choice not to allow the user to opt into clipboard management. Going back to manually typing TOTP codes was more annoying than rooting my phone.
- Hallucinaut 5y ago
  I have a Pixel 6 and I've noticed an app from some Wi-fi lights with an app called TCP Smart copies my clipboard whenever I open it. I was disturbed by this and definitely didn't do anything special to permit it, so that seems somewhat at odds with what you're saying?
  - jeroenhd 5y ago
    Perhaps I misinterpreted; you're right. Foreground apps are perfectly allowed to use the clipboard, it's just background app access that got axed. Apps don't even need any permissions to respond to clipboard events! The toasts were added to Android 12 (https://developer.android.com/about/versions/12/behavior-changes-all#clipboard-access-notifications https://developer.android.com/about/versions/12/behavior-cha...) but the permission required to call from the background isn't available to normal apps. The API should only show for active applications or input methods, and non-IME inputs that call the API (i.e. foreground apps) will show a notification if you have this setting enabled. Basically, it should only happen with the TCP Smart app open, and show when the TCP Smart app is using the clipboard. It shouldn't just randomly happen inside other apps, unless the devs behind that app are somehow bypassing Android's security features.

throwntoday 5y ago

iOS/macOS really need to add clipboard to privacy settings. I opened monopoly on iOS and the first thing it did was paste my clipboard to god knows where.

bagels 5y ago

Why can apps even read it in the first place, as opposed to the os sending it only to apps the user initiates a paste in?

kukx 5y ago
It can be useful of you want to use a non standard way to paste stuff, example a right mouse button in putty.
jchw 5y ago
IMO: you have to look at how OSes and window systems were designed and evolved to get a great answer here. Those processes resulted in systems where the OS or compositor or window system itself can’t really know when the user is pasting something or not. It could be changed, but it would have lots of implications globally, from rewriting framework code, to changing JS APIs. Edge cases would be handled worse, like non-standard paste gestures or VM integration.
kelnos 5y ago
Because the OS doesn't know when the user initiates a paste. The user tells an application that they want to paste, and then the application tells the OS to give it the contents of the clipboard. (Sort of; some windowing systems do it slightly differently, but that's the gist of it.) That's indistinguishable from the application telling the OS it wants to paste when the user hasn't requested it. Sure, there are ways that you could design the system, such as making it so the only way to paste is for the user to hit a key combination, or perhaps click on or touch a UI element that is known to be controlled/hosted/owned by the OS. Then the OS can push the clipboard contents to the foreground application, rather than the application trying to pull it. But then that becomes very limiting, UX-wise. (For example, you wouldn't be able to put a "paste" item in a context menu.) You could also have a permissions model, where the OS prompts for permission every time an app wants to fetch the clipboard contents (presumably with an "I trust this app" option to get it to stop asking). But that might be considered too intrusive, or possibly just ineffective, as people will often just mash at whatever button is closest to get a modal dialog to go away. At any rate, we have these copy/paste mechanisms from when people didn't really think about local security in the way we do today. Redesigning things would break a lot of existing applications. It might be worth it, or it might not.

rank0 5y ago

Is it possible to deny clipboard access to every application and only pass the info through stdin through the explicit ctrl-v or pbpaste/xclip/whatever?

fsflover 5y ago
Yes, on Qubes OS, https://qubes-os.org https://qubes-os.org. It's based on VMs for secure and transparent compartmentalization.
- rank0 5y ago
  I am familiar with Qubes, but I'm asking if this specific security control could be used elsewhere.

tlarkworthy 5y ago

I have taken to copying a benign string after using a sensitive password and I minimize switching tabs during transport of said password.

Gare 5y ago
Some password management programs (I know for KeePassXC) clear the clipboard automatically after several seconds.
- mackatap 5y ago
  Bitwarden does as well, though it seems more like 20-30 seconds.
  - gnabgib 5y ago
    It doesn't by default (perhaps it depends on which version you first installed) but it is available under File -> Settings -> Options: Clear Clipboard which can e set to never/10s/20s/30s/1m/2m/5m.
- SubiculumCode 5y ago
  This is good to know, but it still doesn't help if there is an application phone app, etc, that monitors the clipboard.
npteljes 5y ago
That's a good practice. KeePass 2, KeePassX and KeePassXC, and KeePassDX on Android do this by default as well. It's even better to use the Auto-Type feature of these software, because then the password never gets on the clipboard in the first place.

ZeroGravitas 5y ago

This is part of the reason I don't set Vim to automatically fill the system clipboard and only do so on demand. I think a few other geeky apps let you cut and paste internally as a separate thing from the global clipboard, which seems wise as a mitigation.

adrium 5y ago

Does it really come as a surprise that apps are exploiting the clipboard? TLDR: Drag and drop sensitive stuff. If necessary, copy only part of sensitive information, enter the rest manually. The amount of usability obstacles in the name of security is getting ridiculous. For example, when I got a new company mac, I had to enter my keychain access password and grant access to folders countless times - and I still have to do that after one week of using it occasionally. Similarly annoying are the cookie questions. In the beginning, I found it interesting and tried to reduce the number of cookies as much as possible - now I just click what ever button brings me to the site fastest (or don't click a button at all, if it is still possible to scroll and see about half of the page on mobile). Don't you also feel some kind of fatigue? Now please do not cripple the clipboard the same way. By the way: Qubes OS takes an interesting approach here. Similar to suggestions by some of the commenters. [1] Don't get me wrong: I am extremely sensible to security - but also to usability. I want to use my daily-driver system conveniently and it should "just work" and I want to trust it fully [2]. I do not just install any trash app, simply because there is one available. On the desktop: 1. Only applications from the official repos get installed. I may install other open source software occasionally. So yes, the trust lies with the distro. 2. Other software (potentially untrusted or good to be isolated) like banking or tax software or zoom get a proot environment or a new user profile. 3. Most software can be run in the browser anyway and it is actually quite a nice sandboxing tech. Web apps can not simply read the clipboard. [3] 4. Clear cookies on browser exit. I have a whitelist for about two or three sites to keep the state for convenience. 5. Browser extension that manages and fills passwords on request(!). No need to copy-paste around. [4] 6. If I need passwords elsewhere, I use drag and drop. I believe this is extremely convenient and very secure. That works 90% of the time, otherwise, I copy only part of the sensitive information and enter the rest manually. On mobile: 1. Same goes for app installation: open-source only from F-Droid. 2. Other apps get put in a work profile and disabled when not used. [5] No trash like games and social media. 3. Do not copy paste sensitive information, but use IME apps (keyboard apps that actually "type" passwords). Personally, I like KeePassDX and sometimes use KDE Connect. [6] Accounts: 1. I own several domains and mobile numbers, all companies that want my info get different data. 2. Fill in bogus information if possible. I may have gone overboard with this :-D But I don't even care about MFA that much at this point... And it is an interesting experiment to see what company leaks data. [1] https://www.qubes-os.org/doc/how-to-copy-and-paste-text/ https://www.qubes-os.org/doc/how-to-copy-and-paste-text/ [2] Kubuntu fanboy here and Android still on version 8 though because of ROM customization [3] https://developer.mozilla.org/en-US/docs/Web/API/Clipboard/read https://developer.mozilla.org/en-US/docs/Web/API/Clipboard/r... [4] https://github.com/adrium/easypass https://github.com/adrium/easypass [5] https://f-droid.org/en/packages/net.typeblog.shelter/ https://f-droid.org/en/packages/net.typeblog.shelter/ [6] https://www.keepassdx.com/ https://www.keepassdx.com/ and https://f-droid.org/en/packages/org.kde.kdeconnect_tp/ https://f-droid.org/en/packages/org.kde.kdeconnect_tp/ And I wrote a KeePass plugin to convert the passwords: https://github.com/adrium/KeepassPfpConverter https://github.com/adrium/KeepassPfpConverter

photon12 5y ago

The Qubes clipboard model is one of the reasons I use that OS: https://www.qubes-os.org/doc/how-to-copy-and-paste-text/ https://www.qubes-os.org/doc/how-to-copy-and-paste-text/

alkonaut 5y ago

That my web browser process can read my windows clipboard is fine, what’s important is that it prevents the web pages it has loaded from doing the same. I can’t trust all web pages but trusting all my desktop programs is a much easier pill to swallow. Windows could certainly tighten the security by optionally only allowing foreground/focused apps to access, or notifying the user when apps read the clipboard without being in focus or sent any input first.

badsectoracula 5y ago
> Windows could certainly tighten the security by optionally only allowing foreground/focused apps to access That would break clipboard managers which are very useful tools to have in various occasions. E.g. in a previous job i worked at, some audio designers used a clipboard manager to quickly fill settings in various tool fields. Fun fact: most clipboard managers tend to use global shortcut keys for cycling through the recent N copies (or for pasting specifically tagged content, e.g. copy something and mark it to be used for pasting after Shift+Alt+1 is hit, same for Shift+Alt+2 for something else, etc), which is another thing that you'd hear security concerns for :-P
- nsgi 5y ago
  Sure, but that should really be a permission you have to grant explicitly. For global keyboard shortcuts an app should make commands available and it should be up to the user to tell their OS which shortcuts they want to give an app. Not just for security, but also for customisability and to avoid conflicts
  - badsectoracula 5y ago
    > Sure, but that should really be a permission you have to grant explicitly. That could work but still feels dodgy since if you can grant that permission to a clipboard manager, you can also grant it to something like a TikTok client or an Adobe DRM reader or whatever else program you want to use (ie. the reason you are using your computer in the first place) but also might want to snoop for your data. IMO a better solution that wouldn't break existing clipboard usage is to have a second "secure" clipboard that you can lock as tight as you want with explicit permissions for reading it, notifications for writing to it and whatever else you want. Then password managers would copy data to that and text editors and browsers can have a "Copy Sensitive Data" (or something better worded) in addition to "Copy" that will place data there. Sure some people will still use Copy but some people will also stick post-it notes with their passwords on their monitors and give thousands of dollars to Nigerian princes - you shouldn't to punish everyone for the ignorance of a few. > For global keyboard shortcuts an app should make commands available and it should be up to the user to tell their OS which shortcuts they want to give an app. Not just for security, but also for customisability and to avoid conflicts This only works if all applications are using the same framework and toolkit and target the same OS. Meanwhile notice how even when you limit yourself to applications targeting Windows alone there are tons of different frameworks - let alone cross platform applications that tend to use a lowest common denominator approach. IMO if you want to get more secure functionality, you need to do it in a way that works alongside existing practice - hence containers and sandboxing for untrusted applications working alongside trusted applications that can do what they want. Unless you start everything from scratch on a brand new computing approach (like mobiles did and even then it barely works and despite people treating mobiles almost like consumables), trying to force a top-down approach to security is doomed to fail.

beermonster 5y ago

Is there a Little Snitch/open snitch/Lulu type tool for Clipboard access?

dethos 5y ago
As far as I'm aware, there isn't. And it would be a nice tool to have available, I suspect this could be integrated into existing clipboard managers.

DavideNL 5y ago

Related tool for macOS: https://langui.net/clear-clipboard/ https://langui.net/clear-clipboard/ Clear Clipboard allows you to clear the clipboard content manually or automatically, preventing your clipboard data from being peeped while you are absent. You can chose to clear the clipboard content every few seconds and enable clearing clipboard on computer sleep / display sleep / screen lock to maximize protection of your sensitive clipboard data.

nigwil_ 5y ago
Could use Automator with AppleScript: x@Mac-mini-M1 ~ % cat ClearClipboard.scpt on run tell application "System Events" to set the clipboard to "" end run x@Mac-mini-M1 ~ %

CyberShadow 5y ago

Currently writing a clipboard manager[1], I've seen some things as well. - So far ran into two applications which don't even implement the X11 clipboard specification (ICCCM section 2) correctly - xsel and Emacs (patches submitted). - By far the worst offense I've seen in clipboard privacy on the Linux desktop is RedHat's virt-manager. It sends your clipboard AND selection content to all virtual machines, even when they are not focused, with no indication that it's happening, and with no GUI option to turn it off. This is at odds with the common practice of running untrusted code in virtual machines. - X11 being network-transparent makes its protocol fairly malleable, so it's not difficult to bolt some privacy on top. hax11[2] has an option to restrict access to the primary selection for configured applications (though, for truly malicious applications, you may find X11's security model generally lacking). [1]: https://news.ycombinator.com/item?id=29808487 https://news.ycombinator.com/item?id=29808487 [2]: https://github.com/CyberShadow/hax11 https://github.com/CyberShadow/hax11

thrwawy283 5y ago
I've always wanted an application dedicated to managing the clipboard. It would provide security and even offer interchange conversion that existing apps do not implement. For example: Copying HTML in Windows it has an associated mime type that receiving applications can recognize and choose to convert from. I've always wanted a clipboard/paste manager - with history - like this, that would allow me to copy, manipulate, and paste or share that data to another application. I don't know how this would look, but even the ability to pop open my paste manager and look at the copied contents, filter it, or split the text, or (silly stuff) convert text to emoji'fied content, or take a screenshot of that (text to bitmap), and create a new entry within the paste manager. For some of my friends it would be awesome to have a hex editor in there. Perhaps there are 2 focuses: Isolating what is copied from applications until the user chooses to expose it, and the history function. Being able to send it to another app for manipulation and pulling it back is a 2nd responsibility. It would be /suave/ to have this all in the same GUI brought up by the compositor, though.
- 1vuio0pswjnm7 5y ago
  https://f-droid.org/en/packages/org.dslul.openboard.inputmethod.latin/ https://f-droid.org/en/packages/org.dslul.openboard.inputmet... This replacement keyboard for Android saves clips and allows the user to select and paste them into any application. Most importantly, it allows the user to delete the contents of the clipboard. It also allows the user to "pin" certain clips to be retained for future pasting. Clip storage. If one needs a further reason to replace the keyboard, consider that the default keyboard on Google phones, Gboard, tries to phone home to Google. A keyboard that expects internet access. Incredible.

octavqq 5y ago

hehehe

AshamedCaptain 5y ago

> it seems that due to the nature of X11 it is not possible to know which running process owns the window that is accessing the clipboard. A shame. You definitely can. Search for _NET_WM_PID. Now this being X11, this is again just a convention, and a client could put any information it wants in that property. > While very useful, this raises a lot of security questions. Really, it doesn't. If these programs want to share information, they already can. If these programs want to spy on each other's memory contents, they already can. Unless you are running these programs as different users and with different home directories, which is not usual right now in desktop GNU/Linux (but is on Android).

dethos 5y ago
> You definitely can. Search for _NET_WM_PID. Now this being X11, this is again just a convention, and a client could put any information it wants in that property. That was the reason I mentioned that "it is not possible to know", perhaps "for sure" is missing at the end of the sentence. > Really, it doesn't. As a user (at least in my opinion) it does. > If these programs want to share information, they already can. If these programs want to spy on each other's memory contents, they already can. Unless you are running these programs as different users and with different home directories, which is not usual right now in desktop GNU/Linux (but is on Android). The point is, when the user copies a piece of information he has a clear target for that information (clipboard is the tool he uses do copy from one window to another), why would all other apps have access to it? It is the user that wants to share information not the apps. Even taking account all those capabilities, many pieces of malware rely on detecting and replacing information on the clipboard, that is a clear indication that some sort of isolation is missing here, or at least, and indication regarding that the information was changed/accessed.
- AshamedCaptain 5y ago
  > The point is, when the user copies a piece of information he has a clear target for that information (clipboard is the tool he uses do copy from one window to another), why would all other apps have access to it? Everything that is run by the user runs in the same context. There is little point in focusing on the clipboard, because any two programs running within the same user can do literally anything to each other. Including spying on each other keystrokes, modifying each other's text widgets contents, and faking whatever text/images they are displaying. The fact that they may alter the clipboard contents is irrelevant when they can literally monitor and inject keystrokes on each other. This is the security model that we have right now at the desktop. Good luck trying to find a better one that just does not completely break UNIX and turns it into something like Android. One of the benefit of this model is that you (the user) have practically unlimited freedom in hooking the system in ways that nobody expects (e.g. a clipboard access detector), but then so does anybody else you decide to trust (by running their program in the same context).

abaines 5y ago

With most installations of X11 / Xlib, there is also an extension library: libXFixes. With this, it is possible to receive an event whenever the clipboard (or any other selection) changes (even if our program is not the owner). [0] I used this in the past when porting a Windows text editor to Linux that needed to know when the clipboard had changed. In the C bindings, it corresponds to XFixesSetSelectionOwnerNotifyMask / XFixesSelectionNotifyEvent. There is also a SelectionNotify event in the core X11 protocol, but I'm pretty sure it is different (occurs in response to XConvertSelection - asking for the clipboard contents). Though it has been some time since I wrote the code I'm looking at. [0]: https://www.x.org/releases/current/doc/fixesproto/fixesproto.txt https://www.x.org/releases/current/doc/fixesproto/fixesproto... (6. Selection Tracking)

CyberShadow 5y ago
I think the goal here is to be notified when an application accesses the clipboard, not modifies it. You need to be the owner to do that (excluding some system-wide hack like patching the X server or MITM-ing all X11 connections).

c0l0 5y ago

I think Linux dynamic user probes would lend themselves quite well for something like this. Fooling around with bpftrace for a few minutes yielded this one-liner, which catches all the conscious X11 selection accesses (and a few unconscious ones, too :)) I provoked on my desktop during a few minutes of testing: sudo bpftrace -e 'uprobe:/usr/lib/libX11.so:XGetSelectionOwner{time("%H:%M:%S ");printf("%-6d\n", pid);}' I am not familiar with Xlib/X11 at all, so I am not sure which library functions one would be most interested in to explore this much further. Edit: Replaced `XSetSelectionOwner` with `XGetSelectionOwner` in bpftrace invocation.

CyberShadow 5y ago
I am not familiar with bpftrace (though that does look extremely potent), but XSetSelectionOwner is called when an application wants to make data available via the clipboard, not access it. Also not sure if that would also catch stuff with Xlib, and I guess it won't if it's statically linked (this is why I pivoted hax11 from hooking library calls to MITM-ing the connection).
- c0l0 5y ago
  My bad, I actually had the "production" trace command set to look for `XGetSelectionOwner`, but mis-pasted into my comment ;) Will that fare any better? It did make a few more PIDs/culprits end up in the trace output for me after all. You are correct that "bringing your own function"/shared object will break that particular bpftrace script, but I would assume one could find a way to set up a probe in the X server, where all clients messing with clipboard state via some kind of IPC have to pass thru? (Again, I can only wildly speculate how X11 works under the hood - kinda shameful that I never bothered to look over all these years :-S )
  - CyberShadow 5y ago
    I think XConvertSelection would be more effective. Applications which use the XFixes extension to receive notifications of new owners won't need to use XGetSelectionOwner.

backtoyoujim 5y ago

Then what watches the clipboard watcher ?

dolmen 5y ago
The user.

anderspitman 5y ago

I've been thinking it would be fun to make a self-hosted web clipboard that lets you paste text/files into a simple web page, and have them available on all your devices. Sort of like cl1p.net but e2ee and it would maintain history. You wouldn't need an account because your password could be hashed to yield a unique URL. Only reason I haven't hacked it together already is because I don't trust myself to get the crypto right yet. Anyone aware of something like this already existing?

Damogran6 5y ago
I had thought about something similar, only with publishable subscriuptions so N people could share the same clipboard. Only I wanted the opposite: It would be ephemeral, only as long as you subscribed to the ‘feed’ would you see what was there, there would be no history, and pragmatically, no long term retention in the cloud…mostly as a cost savings measure. I got so far as thinking you’d have two guids: One to subscribe to, and the other to revoke the feed. It never got past the thought stage…and I made a logo and registered a URL that I’ve since let expire as the coding took longer than my attention span.
- tomerv 5y ago
  You're just a few steps away from reinventing Twitter!

juglans 5y ago

Bit Warden password manager app for Linux desktop has an option to clear the clipboard: file -> settings [options]'clear clipboard': dropdown select range from 10 seconds to 5 mins or never. Set & forget.

opan 5y ago
KeePassXC does this as well. Even if just copying the username.

phkahler 5y ago

It would make sense to sniff clipbaod paste commands and offer the active app a one time read access for each user provided interaction. Not sure about the value of requiring the same for writes, but it wouldn't hurt. Any time an unauthorized read is attempted the user could be informed. Not sure where this would get plumbed in. Needs support at the toolkit level (menu->edit->paste) and some higher level outside apps. The idea is to obey the users implicit concent and flag everything else.

jonnypotty 5y ago

I used to support a terminal services/citrix environment and we had repeated instances of people trying to copy and paste data and getting other peoples data. Never got anywhere investigating and boss refused to go to Microsoft. I'd forgotten about it till I read this.

Jenda_ 5y ago

At least, I have a script that runs every minute, and if the clipboard contents has not changed, it flushes it. This really helps in preventing accidental paste of sensitive stuff that remained in the clipboard. I also have script that strips newlines (so I can relatively safely paste into terminal without executing anything) and formatting (so I can paste into WYSIWYG editors). All of this is done by simple xclip -out | ... | xclip -in. There was a bug in stardict: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=806960 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=806960 - if you selected something (i.e., copied to clipboard), it tried to look it up in a dictionary and display a translation (by default, just after startup) - online dictionaries, including one available only over HTTP, were enabled by default - so if you used a password manager that copies passwords into clipboard, they were immediately sent in an unencrypted request for the whole world to see We desperately need an application firewall (something like OpenSnitch, but that's so difficult to configure correctly) and basic app isolation (like QubesOS, but that's heavy and pain to use) for Linux. It's a shame that most other OSes, despite having other problems, implement this correctly.