Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Security Management //


08:05 AM
Larry Loeb
Larry Loeb
Larry Loeb

Decades-Old Vulnerability Allows Spoofing of Encryption Tools

While GnuPG, Enigmail, GPGTools and python-gnupg have all patched the SigSpoof vulnerability, this old flaw shows how encryption tools can be spoofed.

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.

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

Comment  | 
Print  | 
More Insights
Oldest First  |  Newest First  |  Threaded View
COVID-19: Latest Security News & Commentary
Dark Reading Staff 8/3/2020
Pen Testers Who Got Arrested Doing Their Jobs Tell All
Kelly Jackson Higgins, Executive Editor at Dark Reading,  8/5/2020
New 'Nanodegree' Program Provides Hands-On Cybersecurity Training
Nicole Ferraro, Contributing Writer,  8/3/2020
Register for Dark Reading Newsletters
White Papers
Cartoon Contest
Current Issue
Special Report: Computing's New Normal, a Dark Reading Perspective
This special report examines how IT security organizations have adapted to the "new normal" of computing and what the long-term effects will be. Read it and get a unique set of perspectives on issues ranging from new threats & vulnerabilities as a result of remote working to how enterprise security strategy will be affected long term.
Flash Poll
The Changing Face of Threat Intelligence
The Changing Face of Threat Intelligence
This special report takes a look at how enterprises are using threat intelligence, as well as emerging best practices for integrating threat intel into security operations and incident response. Download it today!
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
PUBLISHED: 2020-08-09
** DISPUTED ** Prometheus Blackbox Exporter through 0.17.0 allows /probe?target= SSRF. NOTE: follow-on discussion suggests that this might plausibly be interpreted as both intended functionality and also a vulnerability.
PUBLISHED: 2020-08-08
In JetBrains YouTrack before 2020.2.6881, the markdown parser could disclose hidden file existence.
PUBLISHED: 2020-08-08
In JetBrains YouTrack before 2020.2.6881, a user without permission is able to create an article draft.
PUBLISHED: 2020-08-08
JetBrains YouTrack before 2020.2.8873 is vulnerable to SSRF in the Workflow component.
PUBLISHED: 2020-08-08
In JetBrains Kotlin before 1.4.0, there is a script-cache privilege escalation vulnerability due to kotlin-main-kts cached scripts in the system temp directory, which is shared by all users by default.