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

111–120 of 147 posts

Re: Who keeps an eye on clipboard access?

#111

Post by phkahler »

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.

Re: Who keeps an eye on clipboard access?

#112

Post by jonnypotty »

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.

Re: Who keeps an eye on clipboard access?

#113

Post by CyberShadow »

c0l0 wrote: post #94
CyberShadow wrote: post #90

Earlier quoted context omitted.

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

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

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.

Re: Who keeps an eye on clipboard access?

#114

Post by rank0 »

fsflover wrote: post #9
rank0 wrote: post #8

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?

Yes, on Qubes OS, https://qubes-os.org . It's based on VMs for secure and transparent compartmentalization.

I am familiar with Qubes, but I'm asking if this specific security control could be used elsewhere.

Re: Who keeps an eye on clipboard access?

#115

Post by nitrogen »

IshKebab wrote: post #109
dethos wrote: post #64

Earlier quoted context omitted.

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

Not really though. It makes sense for mobile OSes because they have proper isolation of apps, but desktop OSes don't have that. Apps can pretty much do anything. What's the point of copy notification if apps can just read all your emails and steal all your files anyway. Android and iOS both have this feature already. That's the best we can do for now.

Desktop OSes all have some form of optional sandboxing now, so it makes sense to keep chipping away at the edges of the attack surface.

Re: Who keeps an eye on clipboard access?

#116

Post by adrium »

ummonk wrote: post #108
adrium wrote: post #16

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…

"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." Did you not setup Touch ID?

Hmm... Yes, but I am only aware to use it for unlocking the computer...

Re: Who keeps an eye on clipboard access?

#117

Post by Hallucinaut »

jeroenhd wrote: post #72
rcthompson wrote: post #5

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

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?

Re: Who keeps an eye on clipboard access?

#118

Post by gnabgib »

mackatap wrote: post #44
Gare wrote: post #23

Earlier quoted context omitted.

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

Bitwarden does as well, though it seems more like 20-30 seconds.

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.

Re: Who keeps an eye on clipboard access?

#119

Post by jeroenhd »

Hallucinaut wrote: post #117
jeroenhd wrote: post #72

Earlier quoted context omitted.

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

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?

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

Re: Who keeps an eye on clipboard access?

#120

Post by AshamedCaptain »

CyberShadow wrote: post #97
AshamedCaptain wrote: post #83

Earlier quoted context omitted.

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…

> but for some reason it doesn't seem like the right approach. The approach being used in containerization is namespaces. You can put new processes into a new IPC / user / PID / network / time / etc. namespace, which isolates them from the parent namespace. Once that's done and you can't mess with other processes via the filesystem / kernel, the remaining hole is servers with inadequate security models, such as X11.

What I mean is that if you are going to put your processes as a different user anyway (or a different user namespace), trying to break all the features that allow a user to manage same UID processes is unnecessary.
Post reply on HN