vulnerability on Solid Soft

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.

Simpler and safer artifact signing on CI server with Gradle

Marcin Zajączkowski — Wed, 03 Jun 2020 10:00:00 +0200

Check out how to simplify your Gradle configuration for artifact signing (and releasing) on a CI server (and along the way avoid CVE-2020-13165 in Gradle <6.5).

TL;TR. To get just the short migration recipe, jump to the second to last section.

Releasing from a CI server

Testing, build and releasing (deploying) from CI servers has been more and more popular in the recent years. In many organizations this is something natural. Also multiple FOSS project has started to publish their artifacts to Maven Central (aka The Central Repository) directly from a CI server. This is very nice, as it reduces time to market (or time to release), makes the process less error-prone and removes all the release-related legwork (git commit -m "Trigger release" -m "[#DO_RELEASE]" --allow-empty && git push in many cases can be just enough!).

However, there are also drawbacks of that approach. The CI server - especially in non enterprise environments - is very often a place which has access to all secrets needed to sign and release the software (e.g. the private signing PGP key or the artifacts repository credentials). A data breach from one of the popular SaaS CI servers could open an opportunity to inject malicious code into various popular FOSS projects… Luckily, usually it works fine (or is not actively exploited), however, I cannot resist to mention the vulnerability I have found in Travis back in 2016 which was causing - in some circumstances - to have the build secrets available to anybody in plain text :-/.

There are also some other possible vectors of attack, however, in that article I would like to focus on mitigating the risk of revealing secrets in the system logs, which very often - especially in the FOSS projects - are publicly available.

Gradle and security

Recently, it is pretty visible that the Gradle team takes security very seriously. In January 2020, the HTTP access for Gradle services has been disabled. In February, the verification of Gradle Wrapper was added as an official action for GitHub Actions. A few weeks later, Gradle 6.2 introduced a built-in ability to verify the checksums (and signatures) of the artifacts used in the build process. Starting with Gradle 6.4, using the DEBUG log statement clearly states that it may reveal some secrets and shouldn’t be used in non private builds.

Just released Gradle 6.5 fixes another vulnerability (CVE-2020-13165 ) which I discovered and reported to the Gradle team recently. The earlier Gradle versions might reveal the passphrase for a PGP key used to sign published artifacts, if gpg2 was used together with the INFO log level. This mostly affects CI servers, especially those with the limited (and faulty) secret masking.

I will use CVE-2020-13165 as an excuse to present the simpler artifact signing in Gradle, designed especially for CI servers, which unfortunately is very little-known (an order of magnitude less results on GitHub that a regular useGpgCmd() for GnuPG 2).

PGP artifact signing in Gradle

Originally, Gradle was using the Bouncy Castle library to deal with keys stored in the GnuPG 1 format. However, GnuPG 2 changed the way how keys are kept and their handling has been delegated to a gpg2 process spawn during the Gradle build (which also made it possible to use a system defined gpg-agent program). It was not very convenient on a CI server, where the key usually had to be kept in the encrypted way in the code repository, decrypted with some shell magic during a build using the provided secret and imported into the locally stoped keyring. The procedure was not fully CI server agnostic. In addition, that file could persist on a file system, which especially combined with not using a passphrase could generate some security risk.

Simpler and safer artifact signing

In April 2019, Gradle 5.4 introduced a very nice feature which unfortunately was not even mentioned in the release notes :-(. Marc Philipp (who you may know from his work in JUnit 4/5) implemented a PGP artifact signing optimized for CI servers. Having that in place remote artifact signing is a piece of cake ;-).

Export the private OpenPGP key intended for the CI environment to the ascii-armored form:

$ gpg --export-secret-keys --armor KEY_ID > private-ci.key

Create two secret environment variables on a CI server:

ORG_GRADLE_PROJECT_signingKey = <content of exported private key file>
ORG_GRADLE_PROJECT_signingPassword = <key passphrase>

Enable in-memory signatory provider:

signing {
    useInMemoryPgpKeys(findProperty("signingKey"), findProperty("signingPassword"))
    sign ...
}

And that’s all. Isn’t is simple?

Btw, that mechanism supports also using subkeys (which provide some benefits ).

Summary

As a bonus to simplicity of using the in-memory signatory provider, that method prevents aforementioned passphrase revealing, even in Gradle <6.5. Therefore, it hard to find a good argument against migration :).

Lead photo by Steve Buissinne, published in Pixabay, Pixabay License.