Decades-Old Vulnerability Allows Spoofing of Encryption Tools

Marcus Brinkmann, a security researcher, has announced that many of the most widely used email encryption tools have been vulnerable to signature spoofing since they were first used.

Not only that, the effects of the spoofing can be wider than just invalidating a particular message, Brinkmann writes.

GnuPG, Enigmail, GPGTools and python-gnupg have all been updated to patch this vulnerability (CVE-2018-12020), which Brinkmann has named SigSpoof.

How the spoofing vulnerability works in Enigmail
\r\n(Source: Neopg)\r\n

The GNU Privacy Guard (GnuPG) is a complete and free implementation of the OpenPGP standard which is commonly abbreviated as PGP.

Brinkmann writes:

"The signature verification routine in Enigmail 2.0.6.1, GPGTools 2018.2, and python-gnupg 0.4.2 parse the output of GnuPG 2.2.6 with a "--status-fd 2" option, which allows remote attackers to spoof arbitrary signatures via the embedded "filename" parameter in OpenPGP literal data packets, if the user has the verbose option set in their gpg.conf file."

That's pretty dense, but it unpacks well. The issue boils down to the fact that a user should not have "verbose" in gpg.conf. or use "gpg —verbose" on the command line. It's this verbose command that triggers the vulnerability.

Brinkmann found that GnuPG, with verbose enabled -- either directly on the command line or indirectly through the gpg.conf configuration file -- will print the "name of the encrypted file" field to stderr without escaping newline characters. There is no sanitation done at all to the name field that is being outputted to stderr.

This means that the attacker can inject fake GnuPG status messages into the application parser that follows GnuPG to spoof signature verification and message decryption results. This implies that the attacker can control the key IDs, algorithm specifiers, creation times and user IDs.

Worse, the attacker will not need any of the private or public keys involved to have this ability.

Now entering its fifth year, the 2020 Vision Executive Summit is an exclusive meeting of global CSP executives focused on navigating the disruptive forces at work in telecom today. Join us in Lisbon on December 4-6 to meet with fellow experts as we define the future of next-gen communications and how to make it profitable.

Now, 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.

One may also redirect the log output to a different file, such as "log-file /dev/null."

Also, a user can use --no-verbose when invoking gpg.

There are legitimate reasons for verbose to be enabled. Brinkmann notes that export users might be interested in the additional details that verbose provides. Beginners might run into problems that require verbose to solve.

Brinkmann also outlines a few programs that routinely use this feature of GnuPG. An email client, Gnome Evolution, will add --verbose to GnuPG invocations unconditionally. However, it does use a status file descriptor separate from stderr. This means it is not vulnerable to this attack.

Git verify-commit uses --status-fd 2 to create signatures, but it uses --status-fd 1 to verify detached signatures. Therefore, it is not vulnerable to the attack.

Somehow, this vulnerability escaped review for a long time. The community should be glad it has finally been caught.

Related posts:

— Larry Loeb has written for many of the last century's major "dead tree" computer magazines, having been, among other things, a consulting editor for BYTE magazine and senior editor for the launch of WebWeek.