Parcellite clipboard manager might cause your copied secrets to be stored in the plain-text form in the system logs.
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.
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: xdotool:'/bin/sh -c ‘xdotool mousedown 2 && xdotool mouseup 2’’
… foobar parcellite-startup.desktop: text:‘xxx’
'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.
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.
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.
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 )
A legend: TPA - the Parcellite author.
- 20210919 - me - an initial email to TPA
- 20210921 - me - another email to TPA
- 20210927 - TPA - a response suggesting to create a regular GitHub issue
- 20210927 - me - information to TPA what the issue is and how could be fixed + a suggestion to create a security advisory using GitHub
- 20211005 - TPA - the issue fixed in master
- 20211011 - me - a question to TPA about the new version
- 20211020 - me - another question to TPA
- 20211028 - me - yet another question to TPA
- 20220626 - me - information to TPA 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
- 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 .
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.