GnuPG recently addressed an input sanitization vulnerability where a remote attacker could spoof arbitrary signatures.
Part of the GNU Project and also known as GPG, GnuPG is a complete and free implementation of the OpenPGP standard that enables the encryption and signing of data and communications. The hybrid-encryption software program has a versatile key management system and access modules for all kinds of public key directories.
Released earlier this month, GnuPG version 2.2.8 addresses CVE-2018-12020, a vulnerability affecting GnuPG, Enigmail, GPGTools and python-gnupg, Marcus Brinkmann, who discovered the bug, reveals. Brinkmann has dubbed the flaw SigSpoof.
“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,” he notes.
Status messages, GnuPG maintainer Werner Koch explains, are parsed by programs to get information from GPG about the validity of a signature. Status messages are created with the option “–status-fd N,” where N is a file descriptor. If N is 2, status messages and regular diagnostic messages share the stderr output channel.
The issue resides in the OpenPGP protocol allowing the inclusion of the file name of the original input file into a signed or encrypted message. The GnuPG tool can display a notice with that file name during decryption and verification, but it does not sanitize the file name, meaning that an attacker could include line feeds or other control characters in it.
Because of that, terminal control sequences could be injected, and the so-called status messages could be faked. Furthermore, the verification status of a signed email could also be faked.
“The attacker can inject arbitrary (fake) GnuPG status messages into the application parser to spoof signature verification and message decryption results. The attacker can control the key IDs, algorithm specifiers, creation times and user ids, and does not need any of the private or public keys involved,” Brinkmann explains.
He also notes that status messages need to fit into 255 characters, this being the limitation for the “name of the encrypted file” in OpenPGP.
Brinkmann also published a proof of concept to show how signatures can be spoofed in Enigmail and GPGTools, and another to show how both the signature and encryption can be spoofed in Enigmail. Signature spoofing is also possible on the command line, he demonstrated.
While disabled by default, verbose is included in several recommended configurations for GnuPG, and it is one of the main causes for this vulnerability.
According to the researcher, users should make sure they don’t have verbose in gpg.conf and should avoid using gpg –verbose on the command line. Developers are advised to add –no-verbose to all invocations of gpg.
“The vulnerability in GnuPG goes deep and has the potential to affect a large part of our core infrastructure. GnuPG is not only used for email security, but also to secure backups, software updates in distributions, and source code in version control systems like Git,” Brinkmann claims.
Related: Side-Channel Attack on Libgcrypt Allows RSA Key Recovery
