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

81–90 of 147 posts

Re: Who keeps an eye on clipboard access?

#81

Post by CyberShadow »

AshamedCaptain wrote: post #78
CyberShadow wrote: post #75

Earlier quoted context omitted.

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

> Which distributions and which settings are you talking about?

kernel.yama.ptrace_scope = 1

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

No, you can't. Try it.

> And I rather doubt it is a default, since ptrace-based sandboxing is a thing (even Firefox was using it).

You can trace child processes, but not any other process.

Re: Who keeps an eye on clipboard access?

#82

Post by abaines »

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... (6. Selection Tracking)

Re: Who keeps an eye on clipboard access?

#83

Post by AshamedCaptain »

CyberShadow wrote: post #81
AshamedCaptain wrote: post #78

Earlier quoted context omitted.

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

> Which distributions and which settings are you talking about? kernel.yama.ptrace_scope = 1 > 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). No, you can't. Try it. > And I rather doubt it is a default, since ptrace-based sandboxing is a thing (even Firefox was using it). You can trace child pr…

Which distribution enables this by default ?

EDIT: Apparently Ubuntu, but not Debian, SuSE, Arch, etc. Well, TIL.

> No, you can't. Try it.

You definitely can, it's just that that as you said, gdb just can't attach to anything but a child process; making gdb only work with a process it spawned itself.

Anyway, in addition to changing .profile, you still can do practically everything including modifying SHM segments, writing to pipes, sockets, etc. You could start closing feature by feature (e.g. remove /proc like Android), but for some reason it doesn't seem like the right approach.

Re: Who keeps an eye on clipboard access?

#84

Post by SubiculumCode »

Gare wrote: post #23
tlarkworthy wrote: post #10

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

Some password management programs (I know for KeePassXC) clear the clipboard automatically after several seconds.

This is good to know, but it still doesn't help if there is an application phone app, etc, that monitors the clipboard.

Re: Who keeps an eye on clipboard access?

#85

Post by destructionator »

CyberShadow wrote: post #74
AshamedCaptain wrote: post #68

Earlier quoted context omitted.

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

It is quite easy to do that with X as well. It doesn't transfer data at all until the clipboard data is requested, and at that point, the clipboard owner knows which window is requesting it and is free to ask the user or deny the request. No applications I'm aware of do this in practice though, beyond the normal content negotiation.

Re: Who keeps an eye on clipboard access?

#86

Post by [deleted] »

AshamedCaptain wrote: post #83
CyberShadow wrote: post #81

Earlier quoted context omitted.

> Which distributions and which settings are you talking about? kernel.yama.ptrace_scope = 1 > 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). No, you can't. Try it. > And I rather doubt it is a default, since ptrace-based sandboxing is a thing (even Firefox was using it). You can trace child pr…

Which distribution enables this by default ? EDIT: Apparently Ubuntu, but not Debian, SuSE, Arch, etc. Well, TIL. > No, you can't. Try it. You definitely can, it's just that that as you said, gdb just can't attach to anything but a child process; making gdb only work with a process it spawned itself. Anyway, in addition to changing .profile, you still can do practically everything including modifying SHM segments, wr…

[deleted]

Re: Who keeps an eye on clipboard access?

#87

Post by c0l0 »

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.

Re: Who keeps an eye on clipboard access?

#88

Post by CyberShadow »

destructionator wrote: post #85
CyberShadow wrote: post #74

Earlier quoted context omitted.

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.

It is quite easy to do that with X as well. It doesn't transfer data at all until the clipboard data is requested, and at that point, the clipboard owner knows which window is requesting it and is free to ask the user or deny the request. No applications I'm aware of do this in practice though, beyond the normal content negotiation.

The protocol actually allows for applications to request the clipboard data to be delivered to someone else's window. I haven't tried it, but I think it would work.

Re: Who keeps an eye on clipboard access?

#90

Post by CyberShadow »

c0l0 wrote: post #87

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…

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).
Post reply on HN