[imiric]

It's remarkable to me how we still don't have a security-minded clipboard implementation, seemingly on any OS. It's standard security practice now to use a password manager, but they all[1] exchange critically sensitive data with applications via the clipboard, which is accessible by any application that asks for it. The best we can do is automatically clear the clipboard after a certain time, but this still leaves a wide window for any application to grab the contents. And if you're using a clipboard manager, the standard on Linux DEs, then you have to remember to clear it from there afterwards as well, and suddenly your clipboard manager is a very attractive honey pot.

We need a secure channel for password managers to pass credentials to applications that a) doesn't use the system clipboard, and b) doesn't simulate the keyboard to type into the password field. All modern OSs fail in this regard, AFAICT.

[1]: Except the ones that function as a browser extension and are used for logging into websites. But using something as critical as a password manager from a browser extension might be an even worse security practice than using the clipboard.

[323]

> which is accessible by any application that asks for it

If you have malicious software running on your system, all bets are off. There are many ways it could steal your passwords, since desktop OSes don't sandbox apps like mobile OSes do.

Just one example: you send the password securely to Chrome, but the malicious app just reads the login session cookie from the Chrome user profile files.

Having a secure way of sending a password to an app would indeed be a defense in depth, but fundamentally the system is broken since all apps run with the same permission as the user, thus they can interfere with each other.

[imiric]

> If you have malicious software running on your system, all bets are off.

I think that's a common and lazy response to many security issues. There are _many_ ways in which a nefarious script or program can run in a "secure" environment and wreak havoc. Think NodeJS or Python scripts, which are typically downloaded from untrusted sources and ran blindly by most people as their own (hopefully) unpriviliged user.

> There are many ways it could steal your passwords, since desktop OSes don't sandbox apps like mobile OSes do.

Well, sure, but isn't securing this one major IMO attack vector an improvement over not doing anything about it? I don't follow this defeatist logic of "well, if you're already running malicious software, you're SoL".

Besides, this clipboard issue is also a problem on mobile OSs, since all apps share a global clipboard. Unless some app-specific workarounds are implemented, as mentioned elsewhere in the thread.

[323]

> isn't securing this one major IMO attack vector an improvement over not doing anything about it

Unfortunately securing this attack vector is costly - in the sense of annoying the user with prompts and access grants.

This is why even on mobile as you noticed, only browsers require user confirmation before allowing webpages access to the clipboard.

You could maybe do something in between, like not allowing clipboard access to processes which don't have a foreground window visible to the user.

But in practice, this attack vector is not exploited. If you are targeted, it's much more likely that a specific attack against the password manager is used, since it will extract ALL passwords, and not need to wait for one to show up in the clipboard:

> KeeFarce allows for the extraction of KeePass 2.x password database information from memory. The cleartext information, including usernames, passwords, notes and url's are dumped into a CSV file in %AppData%

https://github.com/denandz/KeeFarce

[imiric]

> Unfortunately securing this attack vector is costly - in the sense of annoying the user with prompts and access grants.

You're making assumptions about what the implementation would be. There are many ways the UX could be unobtrusive. Besides, I'm not even proposing that the solution should be to restrict access to the clipboard. I'm just saying that there should be a secure channel between apps provided by the OS that can be used for these purposes. Designing and implementing that would be costly, sure, but I'm not an OS designer, and merely speaking what I would like to see as a user.

> But in practice, this attack vector is not exploited.

Of course it is[1]. It's not even an exploit, but an abuse of a glaringly insecure OS feature.

> If you are targeted, it's much more likely that a specific attack against the password manager is used

Again, why are you minimizing this clearly easy to abuse OS feature by comparing it to much more sophisticated exploits? Yes, there are other attack vectors. This thread is specifically about how the clipboard is trivially abused.

[1]: https://news.ycombinator.com/item?id=33330035

[323]

> Again, why are you minimizing this clearly easy to abuse OS feature by comparing it to much more sophisticated exploits

You need to think like an attacker. If you gained a foothold on a machine, maybe for a limited time, do you wait until the user happens to login to their banking site by copy pasting the password, or do you comb the machine for everything valuable - files, cookies, password manager databases, ...

If you are sniffing the clipboard you are actively malicious, but then you limit yourself to low gains?

Note that most of the trojans listed in your link are fully featured, sniffing the clipboard is one of the many attacks in their menu.

You are right that it is an attack vector, but it's not a particularly bad one. Microsoft did implement various restrictions which annoy the user, and did implement some protections against common attacks - ransomware file protection, but did nothing regarding the clipboard. Which means that in their cost/benefit analysis it did not stick out as a priority.

[alkonaut]

Applications also have access to global desktop screen recording, which has similar security issues. Basically: the desktop including all user input, frame buffers etc. was created as a free-for-all with security as an afterthought. It's as if all processes run in the same memory space.

I should be able to control which apps can read the screen outside of its own top level window, and be notified when it happens (just like OSes often indicate mic recording). A screen sharing or screenshot app would require the permission and I'd allow it.

Apps that place sensitive content on a clipboard (such as password managers) could use an isolated form of clipboard where only apps that are granted permissions can read. E.g. I copy from my pw manager and when I paste, the OS asks me if I want to allow "Firefox" to read the secure clipboard content from "KeePass".

[ziml77]

macOS actually has these kinds of permissions. The clipboard is still a free-for-all though. I guess that's harder to lock down because it's more than just a simple option of fully allowing or denying access to the clipboard. You would want to be able to paste to any application even if that application can't read the clipboard whenever it wants, but you'd be adding an extra confirmation on every paste if a user doesn't initiate the paste in a way that the OS knows is secure.

[imiric]

I think the solution can be quite simple: allow the user to configure secure channels between apps, sidestepping the main clipboard altogether. So that if e.g. a password manager is configured as source, and the browser as destination, have an option in the password manager to send a password directly to the browser. There would be no intermediary storage like the traditional clipboard, and no typing with a virtual keyboard, just apps communicating directly via a secure mechanism provided by the OS, and configured by the user.

This is already possible by using named pipes on Linux[1], but it has to be built specifically for each app, and anything can go wrong with the implementation. It seems like it would be relatively simple to have this functionality built into the OS.

[1]: https://news.ycombinator.com/item?id=33329561

[xerxesaa]

KeypassXC takes a slightly different approach. It uses named pipes to send the password from the application to the browser extension.

Though the browser is where I find myself using it 95% of the time, they also have an "auto type" feature that will go to the last window and type in your password for you (again, without passing through the clipboard).

[imiric]

Sure, but those are all workarounds for specific uses and operating systems, which require specific integration between the app and the browser.

What I want is a native solution provided by the OS that would work for all apps and scenarios.

[HPsquared]

Drag-and-drop works pretty nicely with most password managers, avoiding the clipboard (in Windows at least).

In Android, it's a case of using a password manager with a built-in keyboard, and having a button available to switch keyboards quickly.

[imiric]

I think those are workarounds with questionable UX. Whereas something as security sensitive as credential access should have a native OS-provided workflow that's secure by default.

[nirimda]

Drag-and-drop seems to have an excellent UX. The semantics are incredibly clear: Take this data from this app and put them into this container in that app. Any insecurities would be an accident of implementation rather than part of the core design like with copy-paste.

Or, how is drag-and-drop insecure by default, and what alternative do you propose?

[imiric]

I'm not saying that drag-and-drop is insecure, but that it's not an ideal UX. I, for one, don't enjoy using it on any OS, and I guess I'm not alone.

The alternative I propose is a native solution from the OS to pass data securely between applications. Not workarounds like drag-and-drop or built-in app keyboards that force me to change my workflow.

[Beltalowda]

Are there "clipboard snoopers" out there? Or more specifically, are there clipboard snoopers that access sensitive data they couldn't also access in any other way?

It seems to me that if you can access the system clipboard you have enough access to do all sorts of stuff.

[323]

There are known cases of malware clipboard snoopers which replaced bitcoin addresses with attacker controlled ones, so if you copy/pasted an address to send bitcoin to, you would end up sending it to the attacker.

https://techcrunch.com/2018/07/03/new-malware-highjacks-your...

[imiric]

> Are there "clipboard snoopers" out there?

I haven't run into any (that I know of), but it's trivial to write such a program.

> are there clipboard snoopers that access sensitive data they couldn't also access in any other way?

There's no such thing as a 100% secure system, but removing one of the most vulnerable attack vectors is a huge improvement in and of itself.

> It seems to me that if you can access the system clipboard you have enough access to do all sorts of stuff.

Not quite. Currently all applications have unrestricted access to the clipboard. Accessing decrypted credentials in a password manager is only possible by the authorized user, and this can be restricted in a number of ways. Maybe we need a stricter permission system for clipboard access, but I would argue we need to stop using the clipboard for exchanging sensitive data between applications.

[Beltalowda]

It's indeed trivial to write such a thing, and given that none seem to exist it doesn't seem like it's really a practical security issue IMHO.

I think a permission system for the clipboard would be pretty awkward UX, and not really worth the effort for the (hypothetical) problem it's solving.

[jdsnape]

Yes - for example https://github.com/slyd0g/SharpClipboard

This is designed to work with CobaltStrike, which is a tool used by security testers (i.e. redteams), but also by real life adversaries as well.

[Beltalowda]

So has anyone every used that as an attack vector? Some proof-of-concept code is not hard to write.

[jdsnape]

yes - see https://attack.mitre.org/techniques/T1115/ for a non-exhaustive list

[hoseja]

Look into the implementation in KeePass, it at least does some mitigations.