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
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.
to post comments)