CLD-425 Details

Other IDs this deficiency may be known by:

Basic Information:

Version Specific Information:

Details:

=================================== Overview ===================================

mainproc.c in GnuPG before 2.2.8 mishandles the original filename during
decryption and verification actions, which allows remote attackers to spoof the
output that GnuPG sends on file descriptor 2 to other programs that use the
"--status-fd 2" option. For example, the OpenPGP data might represent an
original filename that contains line feed characters in conjunction with
GOODSIG or VALIDSIG status codes. 

================================ Initial Report ================================

From https://lists.gnupg.org/pipermail/gnupg-announce/2018q2/000425.html:

Impact
======

All current GnuPG versions are affected on all platforms.

All mail clients and other applications which make use of GPG but are
not utilizing the GPGME library might be affected.

The OpenPGP protocol allows to include the file name of the original
input file into a signed or encrypted message.  During decryption and
verification the GPG tool can display a notice with that file name.  The
displayed file name is not sanitized and as such may include line feeds
or other control characters.  This can be used inject terminal control
sequences into the out and, worse, to fake the so-called status
messages.  These status messages are parsed by programs to get
information from gpg about the validity of a signature and an other
parameters.  Status messages are created with the option "--status-fd N"
where N is a file descriptor.  Now if N is 2 the status messages and the
regular diagnostic messages share the stderr output channel.  By using a
made up file name in the message it is possible to fake status messages.
Using this technique it is for example possible to fake the verification
status of a signed mail.

Although GnuPG takes great care to sanitize all diagnostic and status
output, the case at hand was missed but finally found and reported by
Marcus Brinkmann.  CVE-2018-12020 was assigned to this bug; GnuPG tracks
it at .


Solution
========

If your application uses GPGME your application is safe.  Fortunately
most modern mail readers use GPGME, including GpgOL and KMail.  Mutt
users should make sure to use "set crypt_use_gpgme".

If you are parsing GnuPG status output and you use a dedicated file
descriptor with --status-fd you are safe.  A dedicated file descriptor
is one that is not shared with the log output.  The log output defaults
to stderr (2) but may be a different if the option --logger-fd is used.

If you are not using --verbose you are safe.  But take care: --verbose
might be specified in the config file.  As a short term mitigation or if
you can't immediately upgrade to the latest versions, you can add
--no-verbose to the invocation of gpg.

Another short term mitigation is to redirect the log output to a
different file: For example "--log-file /dev/null".

The suggested solution is to update to GnuPG 2.2.8 or a vendor provided
update of their GnuPG version.

To check whether the bug has been fixed you may use the simple test at
the end of this mail [1].

================================= Our Analysis =================================

----- Affected Products -----
GnuPG 2.1.16 is vulnerable. This includes GnuPG as originally packaged in
Cucumber Linux 1.0 and 1.1.

----- Scope and Impact of this Vulnerability -----
Allows for injecting terminal control characters and faking successful
signature verification when verifying a signature with gpg.

----- Fix for this Vulnerability -----
This vulnerability can be fixed by upgrading GnuPG to version 2.2.8 or newer, or
by applying the patch from
https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=patch;h=210e402acd3e284b32db1901e43bf1470e659e49.

================================= Our Solution =================================

We have applied the aforementioned patch and rebuilt.