GnuPG signed message spoofing vulnerability

An advisory about a problem in GNU Privacy Guard (GnuPG) would normally cause worries about an implementation flaw leading to insecurely encrypted data. Thankfully, this particular vulnerability does not fall into that category and data encrypted using GnuPG is not at risk from it; it is, instead, a hole which allows attackers to spoof signatures. This vulnerability highlights an interesting interaction between GnuPG and the applications that use it. The flaw is not so much in how GnuPG does its work, rather it is in how it presents it.

GnuPG is an implementation of the OpenPGP standard which governs messages encrypted with public-key encryption. The standard is described in RFC 2440 and is descended from the original Pretty Good Privacy (PGP) program that Phil Zimmerman released (much to the chagrin of the US Government) in 1991. Many different mail programs use GnuPG (or the related GnuPG Made Easy (GPGME) library) to handle encrypted email; these programs include most open source email clients (KMail, Evolution, Thunderbird via the EnigMail plugin, mutt, etc.). All are vulnerable to the spoof - as is the gpg command-line tool, depending on how it is used.

One of the features of OpenPGP is digital signing of messages so that the recipient can ensure that the message they receive is the same as the one that was sent. It is this digital signature that is vulnerable to this attack as it can be spoofed; making it appear that unsigned text is covered by a valid signature. An attacker can insert malicious text into an existing message and have it appear to have been sent by the signer.

OpenPGP messages consist of a set of "packets" that correspond to different sections of a message (plaintext, encrypted, signature, compressed, ascii-armored, etc). Taking two valid OpenPGP messages and concatenating them produces a longer, but still valid, OpenPGP message. The simplest way to exploit the flaw is to take a plaintext packet and add it to the front of a signed plaintext packet. If the user attempts to verify the message by invoking gpg < msgfile, they will see the contents of both of the plaintext packets followed by a statement that the signature was verified. Nothing in the output indicates the presence of two packets with different signature status.

If this were the only issue, there would be a relatively easy, but not completely satisfying, workaround; do not redirect stdin from a file when using gpg. When it is invoked as gpg msgfile, GnuPG writes each individual plaintext packet into a separate file and, depending on the filenames specified in the packet, the above example would either create two files or prompt asking whether to overwrite when it encounters the second packet. That prompt, or the presence of two files, might be enough to alert the observant user to an anomaly, but is hardly foolproof. Unfortunately, mail clients typically invoke gpg via the output end of a pipe which allows them to be spoofed.

GnuPG does provide the --status-fd mode to prevent just this kind of attack by producing more status information on the specified file descriptor. The status information is not particularly user-friendly and might not alert a casual user to the spoof, but it certainly can be used by a program to detect the spoof. This is how GnuPG recommends that it be used by other programs but the developers of many mail clients ignored that advice with the result that their code is vulnerable. Normally this might be considered a problem for the mail client developers to solve, but the GnuPG team decided to make changes to GnuPG and GPGME to alleviate the problem.

Updated versions of GnuPG will no longer process multiple messages in a single invocation, avoiding the mingling of packets with different signature status. GPGME has been changed to avoid the spoofing even when it is using a vulnerable version of GnuPG. It is likely that the various mail clients will need to be updated eventually as well because they may well rely on GnuPG to process multiple messages in a single pass. The mail clients may not correctly process all of the email types that they did in the past, but they will not be vulnerable to this kind of attack.

The advisory has a wealth of information about the flaw and various ways that it can be exploited; it is well worth a read for those interested. This is an interesting bug because it lives between the GnuPG software and its users (both human and program). The GnuPG developers could have pushed this off as a problem for those users, but took a more helpful approach. If the command-line version (gpg < msgfile) of the flaw did not exist, it seems possible that they would have chosen differently and the mail client development teams would instead be scrambling to release updates.