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

Who keeps an eye on clipboard access?

blog.ovalerio.net

Post reply on HN
Print view View original

61–70 of 147 posts

Re: Who keeps an eye on clipboard access?

#61

Post by Rygian »

CyberShadow wrote: post #45

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?

Re: Who keeps an eye on clipboard access?

#62

Post by AshamedCaptain »

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

Re: Who keeps an eye on clipboard access?

#63

Post by kibwen »

alkonaut wrote: post #30

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

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

To be clear for others who may be reading this, this statement isn't a hypothetical, web browsers do prevent web pages from reading the clipboard.

Re: Who keeps an eye on clipboard access?

#64

Post by dethos »

alkonaut wrote: post #30

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

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

Author here, yes, this is indeed the point of the article. Desktop operating systems could/should have implemented such a feature a long time ago, it is clearly a security "blind spot" at the moment.

Re: Who keeps an eye on clipboard access?

#65

Post by dethos »

AshamedCaptain wrote: post #62

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

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

Re: Who keeps an eye on clipboard access?

#67

Post by indentit »

thrwawy283 wrote: post #50
CyberShadow wrote: post #45

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…

For Windows, there is "ClipboardFusion" by Binary Fortress, which acts as a scriptable clipboard manager, and could tick most of your boxes.

I'm not sure how possible it would be on Windows for a third party app to perform isolation - maybe if it registers a hook for when clipboard content changes which is somehow guaranteed to run first before other applications and any hooks they may have, it could swallow the event and clear the clipboard so other processes can't see it, and then do something similar with paste events maybe?

Re: Who keeps an eye on clipboard access?

#68

Post by AshamedCaptain »

dethos wrote: post #65
AshamedCaptain wrote: post #62

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

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

Re: Who keeps an eye on clipboard access?

#69

Post by bryanrasmussen »

badsectoracula wrote: post #57
bryanrasmussen wrote: post #49

Earlier quoted context omitted.

>That sounds like a usability nightmare. sure but any email system should not have to request the capabilities to do any of these things, so basically if a message came in and it started requesting these capabilities - it would only be malicious messages that would do it. This is following the principle of least access/authority http://wiki.erights.org/wiki/POLA

An email client certainly needs the capabilities mentioned there. The ILOVEYOU virus (which is what the page refers to) was an executable (a VBS script but any executable could do the same thing) that asked Outlook Express for the address book and use it to send mail with itself as an attachment. The issue with it was that Outlook Express was too happy to run programs attached to mail (also that Windows hide file ext…

so, I can't help but note that when I said an email client should not need to request these capabilities and anything that did would be malware, you said an email client definitely needed to request these capabilities and gave as the example the ILOVEYOU virus.

Re: Who keeps an eye on clipboard access?

#70

Post by [deleted] »

badsectoracula wrote: post #60
laumars wrote: 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…

[deleted]
Post reply on HN