Security issue in Parcellite <= 1.2.1

[szpak]

TL;TR. Parcellite clipboard manager might cause your copied secrets to be stored in the plain-text form in the system logs.

Please note. This issue provides only a subset of information. The full announcement can be found here: https://blog.solidsoft.pl/2022/06/28/security-issue-in-parcellite-1.2.1/

Vulnerability

If started automatically by a .desktop file, in systemd powered environment (reproduced with Fedora), every copied text (including credentials) might be logged in a plain-text form in the system logs:

… parcellite-startup.desktop[5354]: xdotool:'/bin/sh -c ‘xdotool mousedown 2 && xdotool mouseup 2’’ … foobar parcellite-startup.desktop[5354]: text:‘xxx’

where 'xxx' can be anything copied by an user, including user’s passwords and API keys.

Affected systems/users

The issue can only affect desktop users using Parcellite 1.1.7 to 1.2.1 (1.2.2 with the fix is not yet released at the time of creating this issue) on X.Org Server (Parcellite does not work with Wayland).

Dealing with (potentially) compromised credentials

It is best to roll/change all the credentials (and other secret) copied into a clipboard when Parcellite was running. The journalctl -u -ball parcellite-startup.desktop command might be useful.

If changing the secrets is problematic or not possible (e.g. your SSN or your credit card number), it is possible to:

• remove the affected journal files
• rewrite the history in the affected journal files (which is not easy, but is possible)

Timeline

Originally reported in September 2021. Fixed in master in October 2021. New version with the fix - none available at the moment of creating this issue.

Check my official announcement for complete timeline.

Further actions

1. Convince the Parcellite author to finally release 1.2.2.
2. Notify the package maintainers to upgrade the version (or apply a patch )
3. Request for the CVE number - it would be good to be obtained by the project author, possibly using the mechanism provided by GitHub .

Postscriptum

I realize that opening security-related issues in a public issue tracker is not the best idea and that GitHub provides a dedicated mechanism for that, however, I has been not able to convince the Parcellite maintainer to follow that way (for months).

[rickyrockrat]

I know you want to be recognized for a 'security' bug, but most people run their own computers. In the rare case there is a multi-user Linux box, your concerns are valid, but for the vast majority of us, this is not an issue.

And the truth of the matter is that ANY security related things like passwords are all readable by root, who is ideally the only one with access to the journal entries. So basically, all clipboard managers are insecure that save history in a file somewhere without a hash, so you should file bugs with all the major clipboards for Linux.

[szpak]

In the rare case there is a multi-user Linux box, your concerns are valid, but for the vast majority of us, this is not an issue.

It's not just a multi-user Linux box. Some people still don't use full disc encryption and those (potentially critical) passwords (e.g. to a password manager, to your bank account or a YT account ;-) ) are available offline (stolen/lost laptop, sold hard disk without cleaning).

So basically, all clipboard managers are insecure that save history in a file somewhere without a hash, so you should file bugs with all the major clipboards for Linux.

I would not agree. If anyone enabled saving passwords to an (unencrypted) file, this it his/her decision. However, in that case it's an explicit user action (or at least awareness, it is enabled). In this situation with Percellite, it's a default, (accidentally) hidden behavior, people would definitely not expect.

Btw, I remember "similar" issue with some old Ubuntu - CVE-2006-1183. Old a password kept plain text in the logs (the root password, so slightly more dangerous, but following the above argumentation, it should be just an enhancement - however, it has its own CVE, it has the "critical" importance in the issue tracker, and it is referred by some people as "extremely critical bug and security threat" ;-)

"An extremely critical bug and security threat was discovered in Ubuntu Breezy Badger 5.10 earlier today by a visitor on the Ubuntu Forums that allows anyone to read the root password simply by opening an installer log file.

I know you want to be recognized for a 'security' bug [...]

No, not really. I've found some other security "issues" before and I just do it for prevent them from being exploited and to have them fixed (usually it's easier to make them fixed :-( ). I'm not a professional security research (even not an amateur one - the vulnerabilities just meet me...

[szpak]

Btw, I have noticed the version 1.2.2 had been released. It's good. Please put some information in the changelog/release notes about "unlikely, but potential credentials leak" in the previous versions. Just to let those who are concerned about their security a way to get know about it. Thanks.

[ernstki]

I know you want to be recognized for a 'security' bug, but most people run their own computers. In the rare case there is a multi-user Linux box, your concerns are valid, but for the vast majority of us, this is not an issue.

I, for one, appreciate the effort that went into reporting this. Ten years ago I might've agreed with you about this not being an issue for a personal computer, but I don't anymore. This is exactly the kind of "secrets" file that criminals and law enforcement alike are going to go looking for, the minute they get remote access, or get their hands on a laptop. I'm not even being paranoid, it's just how the world works now.

So basically, all clipboard managers are insecure that save history in a file somewhere without a hash, so you should file bugs with all the major clipboards for Linux.

But Parcellite doesn't if you disable the disk history file. That's why I'm using it, instead of some other one. I was still horrified when I found the clipboard history world-readable on my (Debian-derived) system, but that's the packager's fault, not yours. Maybe there could be a check for that.

Parcellite could do a lot worse. It could try and synchronize the clipboard with a cloud service, like the clipboard history feature on Windows (Win+V) does, if you let it. It could also do a lot better, including its maintainer not being dismissive of totally legit user concerns like this one, or defaulting to no persistent history.

@rickyrockrat Would you be amenable to documentation patches that at least mention some of the concerns brought up here? I'd also be willing to look into doing a quick check for permissions on the history file, if configured.