Security issue in Parcellite <= 1.2.1

Marcin Zajączkowski — Tue, 28 Jun 2022 22:00:00 +0200

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

TL;TR. Parcellite might cause your copied secrets to be stored in the plain-text form in the system logs. To check if your system is affected jump to the “appropriate” section below.

Background

I am an avid user of clipboard managers. In fact, I cannot image how I could stop using that feature (and how can people live without it ;-) ). An ability to be able to refer to the previously copied text entries is a productivity booster in many cases. Unfortunately, modern Linux desktop environments complicate the thing (precisely Wayland - a “new” display server protocol), ironically, due to the security concerns, not providing any sensible alternative.

Some time ago, I was experimenting with some alternative clipboard managers. Parcellite was one of them and I have discovered not a very pleasant behavior.

Vulnerability

parcellite 1.2.1 on Fedora (tested with F34 and parcellite-1.2.1-6.fc34.x86_64) is by default automatically started using a .desktop file. That result in having it caught by the journal systemd daemon and the output (stdout and stderr) is in a default configuration kept in the journal files. It can be:

… 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. The entries are user accessible (via journalctl), so every (potentially
malicious) application could read it. The old journal files - depending on the system configuration - can be kept for months (or longer), so systems with an unencrypted hard disc provide also an alternative vector of attack.

The output is generated in that place :

cmd = g_strconcat("/bin/sh -c 'xdotool ", action, NULL);
g_fprintf(stderr,"xdotool:'%s'\ntext:'%s'\n",cmd,txt);

which was added as an enhanced debug statement back in 2013 . This suggests that versions 1.1.7 to 1.2.1 can be affected.

That behavior does not require persisting clipboard entries across system restarts (which generates similar security risk and is disabled by default).

As the aforementioned .desktop file is provided by the upstream project, the other Linux distributions using it to automatically start Parcellite on user log in most likely are also affected.

Fix

Upgrade to 1.2.2 (once released) or to the patched versions of 1.2.1 if available in your distribution repository.

As a workaround, disable auto start for Parcellite using the .desktop file and run it manually.

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 publishing that advisory) on X.Org Server (Parcellite does not work with Wayland).

The problem was originally reproduced with Fedora 34 (the newest version at the time of discovery), but probably the majority of other distros using systemd with the modern journal are also affected. Please let me know (via mail or in comments) if your distro is affected and I will update that section.

If unsure, copy some text into clipboard and check journalctl -u parcellite-startup.desktop for the copied value. If found, the system is affected.

This vulnerability is NOT (easily) exploitable from the internet. A successful attack requires live access to the system with a (current) user permissions (e.g. any application running by that users) or offline access to an unencrypted disk/storage with the system logs.

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

A legend: TPM - the Parcellite maintainer.

20210919 - me - an initial email to TPM
20210921 - me - another email to TPM
20210927 - TPM - a response suggesting to create a regular GitHub issue
20210927 - me - information to TPM what the issue is and how could be fixed + a suggestion to create a security advisory using GitHub
20211005 - TPM - the issue fixed in master
20211011 - me - a question to TPM about the new version
20211020 - me - another question to TPM
20211028 - me - yet another question to TPM
20220626 - me - information to TPM about my intention to reveal the issue anyway (as the new version is not yet released after 9 months)
20220628 - me - release the vulnerability description on my blog and in the public issue on GitHub
20230311 - TPM - release Parcellite 1.2.2, containing the fix

Further actions

~~Convince the Parcellite author to finally release 1.2.2.~~
~~Notify the package maintainers to upgrade the version (or apply a patch )~~
Request for the CVE number - it would be good to be obtained by the project author, possibly using the mechanism provided by GitHub - UPDATED. I was unable to get one :-(.

Updated 2020-05-21. Mention recent Parcellite 1.2.2 release, rename TPA to TPM + update the “further actions”.

Summary

I am just an off-the-clock security researcher, but having some (potentially) security-related problems (accidentally) spotted, I like to have it reported and fixed to do not expose other people and systems at risk. Thanks to my previous findings the users of (among others) Travis and Gradle can sleep (slightly more) peacefully :-).

Lead photo by tsmr, published in Pixabay, Pixabay License.

secrets on Solid Soft