Multiple Vulnerabilities Found in GnuPG

Gnu Privacy Guard, a popular implementation of the OpenPGP standard, was found to have multiple vulnerabilities including modifying the plaintext shown to the user and modifying files on the user’s system.

Security researchers published their findings on gpg.fail and presented a talk at the Chaos Communication Congress. The 14 listed flaws are as numerous as they are alarming, especially for such a trusted piece of software used to keep private communications safe.

The first attack allows an attacker to “arbitrarily swap the plaintext shown to a GnuPG user, when the user verifies a detached signature versus views it with --decrypt.” Any situation when an attacker can swap the content of your E2EE messages is quite bad. The issue is symptomatic of how the software handles checking signatures as a whole:

In the long run, the state machine should be reworked. A lot of security-critical mechanisms like c->any.data and other multiple plaintext mitigations are dependent on state and are measured in brittle ways, e.g. by checking for detached vs. full/clear signatures by counting the plaintext packets while parsing, instead of checking ahead of time whether the shape of the input is sane.

The next vulnerability can "lead to creation or overwrite of any file on the system the user can write to. This commonly includes regularly executed scripts and programs leading to remote code execution (RCE)."

Attack number three allows a message that contains \f\n to have arbitrary text added at those points and still successfully verify. The attacker needs access to the plaintext and the signature for the message.

There’s a vulnerability in Modification Detection Codes, which are meant to protect the integrity of the encrypted message. The problem lies in that GPG allows for inputs known to be harmful and that attackers can modify packets in a way that appears harmless. According to the researchers ”a user might be tricked into decrypting and publishing a secret encrypted message, e.g. by changing packet types of a secret message to look like a public key packet.”

PGP is a standard originally from 1991, and as such it’s had a long and storied history of problems in and of itself, not to mention the clients such as GPG which can introduce their own issues.

While it’s now an open standard called OpenPGP, it still lacks many of the features of a modern messenger like Signal. No forward secrecy so if your key leaks, all previous messages are now compromised. You have to manage your own keys, making the aforementioned scenario more likely. There’s no post-quantum encryption either leaving you potentially vulnerable to ”harvest now, decrypt later” attacks.

The previous EFAIL E2EE vulnerabilities showed just how flimsy the E2EE guarantees of OpenPGP can sometimes be:

The EFAIL attacks exploit vulnerabilities in the OpenPGP and S/MIME standards to reveal the plaintext of encrypted emails.

While E2EE messengers like Signal are constantly adding new features and strengthening their security, OpenPGP is left struggling with backwards compatibility and decades of technical baggage. It leaves you wondering if OpenPGP is possible to bring up-to-snuff or if we should just scrap it and start over.

Work is being done on updating OpenPGP with modern features such as post-quantum cryptography, forward secrecy, and improved key verification UX such as key transparency and verifying keys using a QR code. This is admirable and I’m excited to see what they’re able to do with it, however not everyone seems to be onboard.

In a blog post on the GPG site, they state “GnuPG and OpenPGP are extremely mature and basically "done" and “no one seriously considered GnuPG or OpenPGP to be practically vulnerable to attacks.” This is concerning when, on top of lacking modern features expected of a secure messenger, new vulnerabilities are still being found in their software.

It remains to be seen what the future holds for PGP. Email is likely here to stay for the foreseeable future due to the network effect and how entangled it is with almost everything from bank accounts to online accounts. At the very least, we should push for higher standards for the software we depend on to keep our communications safe.