Live data from Hacker News

Who keeps an eye on clipboard access?

blog.ovalerio.net

71–80 of 147 posts

Re: Who keeps an eye on clipboard access?

#71
post #61

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

> RedHat's virt-manager. It sends your clipboard AND selection content to all virtual machines Do you know what's the CVE for that one?

Let's see where this goes:

https://github.com/virt-manager/virt-manager/issues/358

Edit: found this, so maybe Red Hat considers this a feature which is working by design: https://github.com/virt-manager/virt-manager/pull/166

Re: Who keeps an eye on clipboard access?

#72

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.

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.

Re: Who keeps an eye on clipboard access?

#73
post #58

Earlier quoted context omitted.

> Note that what i refer to is not about breaking any standard API but adding a secondary one that is explicitly about secret/sensitive stuff. But it still requires developers to use a new API. So why get them to used a half arsed security enclave when you can design a proper secrets store instead? > If the source of the data to be placed in the secure clipboard (for lack of a better name) is some encrypted storage (…

> But it still requires developers to use a new API. So why get them to used a half arsed security enclave when you can design a proper secrets store instead? Because the entire point of this is NOT to store something but to transfer something from one application to another without both applications explicitly knowing about each other (so they can't just communicate in a P2P fashion). The rest of your message is abo…

I get that you’re not storing something long term, but you are still storing it even if it is short term and thus presenting a risk. And you are still sharing secrets between applications thus presenting a risk. And all your suggestion is doing is offering a kludge around a solution you’ve already said is crappy, rather than switching to a robust and battle tested solution that literally every other platform already supports.

If you want to pass secrets securely between applications then you use a secrets manager. It’s how Linux and macOS work. It’s how secure systems in the cloud works. And thus it makes complete sense for Windows to follow suit. We aren’t talking about some theoretical concept here. It is absolutely how passing secrets between applications should be done.

If you have scepticism about this approach then you need to read up in this topic rather than pushing for a half baked kludge around something you’ve already acknowledged isn’t fit for security.

Sorry if this sounds blunt but this is a solved problem you’re trying to re-engineer and your solution is worse than the industry standard in a number of ways which I’ve already highlighted. And ironically it isn’t even just worse for security but also worse for usability well (you’re creating administrative overhead with the user approving safe applications. This wouldn’t be needed with a secrets manager since each application only has visibility of its own enclave). And if you remember back to your first post, usability was the entire reason you designed this solution in the first place.

Re: Who keeps an eye on clipboard access?

#74
post #65

Earlier quoted context omitted.

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

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

This is why distributions are moving towards Wayland and container-izing most applications; this allows each application to be in its own sandbox with no capability of interacting with other applications without the user/system's explicit consent.

Re: Who keeps an eye on clipboard access?

#75

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

> If these programs want to spy on each other's memory contents, they already can.

No, they cannot. As an unprivileged process, you cannot access other processes' memory, with major distributions' default settings, even if the two processes share the same UID. The only way to achieve that would be to modify some execution path (e.g. .bashrc) to launch an evil wrapper which runs the target process in a way that allows reading its memory.

Re: Who keeps an eye on clipboard access?

#76
post #61

Earlier quoted context omitted.

> RedHat's virt-manager. It sends your clipboard AND selection content to all virtual machines Do you know what's the CVE for that one?

Let's see where this goes: https://github.com/virt-manager/virt-manager/issues/358 Edit: found this, so maybe Red Hat considers this a feature which is working by design: https://github.com/virt-manager/virt-manager/pull/166

Qubes distinguishes local and global clipboards for exactly this reason.

Re: Who keeps an eye on clipboard access?

#77
post #35

Earlier quoted context omitted.

It’s pretty safe in web browsers. Any app can write to it but the only way to read is if the user hits the paste shortcut.

That is not quite true. JS can read the clipboard on any direct user interaction using "Document.execCommand". Also, there is a newer Clipboard API that requires explicit user permission, but as far as I understand once it is given it allows arbitrary reads.

On my browser (Firefox 96), the paste command seems to just return false and do nothing.

Re: Who keeps an eye on clipboard access?

#78

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

> If these programs want to spy on each other's memory contents, they already can. No, they cannot. As an unprivileged process, you cannot access other processes' memory, with major distributions' default settings, even if the two processes share the same UID. The only way to achieve that would be to modify some execution path (e.g. .bashrc) to launch an evil wrapper which runs the target process in a way that allows…

Which distributions and which settings are you talking about?

If you can run gdb on that distribution, then you can definitely do it, even if it's just because they whitelist gdb in selinux/aa (in which case you can just script gdb). And I rather doubt it is a default, since ptrace-based sandboxing is a thing (even Firefox was using it).

And as for the second method, that's why I said same home directory. But there is a gazillion of ways. You can even meddle in practically all IPC done by any two processes of the same UID, e.g. attach to sysv or posix shm.

Re: Who keeps an eye on clipboard access?

#79
post #35

Earlier quoted context omitted.

That is not quite true. JS can read the clipboard on any direct user interaction using "Document.execCommand". Also, there is a newer Clipboard API that requires explicit user permission, but as far as I understand once it is given it allows arbitrary reads.

On my browser (Firefox 96), the paste command seems to just return false and do nothing.

Are you running it as part of a click handler?

Re: Who keeps an eye on clipboard access?

#80

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

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, manipula…

That does sound great.

While it's not what you're looking for, a lot of people also don't know that windows has a built-in copy paste history if you use windows+v instead of ctrl-v. That's quiet handy too, but a fast cry from what you've proposed there

Post reply on HN