SigSpoof: Spoofing signatures in GnuPG, Enigmail, GPGTools and python-gnupg | Hacker News Reader

SigSpoof: Spoofing signatures in GnuPG, Enigmail, GPGTools and python-gnupg

neopg.io

107 pointssphinxc0re19 comments

I like how this vulnerability report gives a reasonable set of actions for mitigations:

For Users

    Remove verbose from gpg.conf, if you have it.
    Do not use gpg --verbose on the command line.
    Upgrade to GnuPG 2.2.8 or GnuPG 1.4.23
    Upgrade to Enigmail 2.0.7
    Upgrade to GPGTools 2018.3

For developers

    Upgrade to python-gnupg 0.4.3
    Call gpg with --no-verbose to disable the attack.
    Use a dedicated pipe for --status-fd, and do not share it with stderr.
    If this is not easy (or even possible) due to the framework or target platform, consider --batch --log-file FILE to redirect the stderr output, where FILE can be /dev/null, too. Thanks to Patrick Brunschwig for this idea!
    Or, the --status-file FILE option could be used to direct the status lines to a temporary file.

I am pretty baffled by the fact that anyone relies on output parsing for verifying a signature. Is this common? I suspect that we will see more vulnerabilities like this in that case.

If one relies on a command line tool for doing this, wouldn't it be safer to have a command line switch which lets the program exit with 0 if the verification succeeds and another value if it fails?

Has anyone an elif what the fix would be? Just altering a switch (which I suspect) would be a band-aid, imho.

Return code doesn't help this time because there is more than one kind of correct input. There can be valid encrypted message, valid signed message or combination of both. In the attack valid encrypted message was made to look like valid signed message. For both verification would succeed unless you know what the message is supposed to contain before processing it with gpg.

As already suggested output parsing here is necessary due to multiple possible outcomes.

I just want to add that if you have to parse command output, enforce the output format as well as you can. The --verbose bug really shouldn’t have happened.

As I am mainly a Java guy it has burnt into me to never rely on .toString() output for code flow. It seems to me that this is somewhat similar (or has the Unix world a gentlemans agreement that output has an API contract). I'd never touch anything where I couldn't enforce (preferably typed) output to rely on especially in a security context. I think I have already seen command line tools which can return structured content (json, xml) with a switch (I don't remember which, though).

awscli tools can generally do so.

> I have already seen command line tools which can return structured content (json, xml) with a switch

That happens. It doesn't need to a standard format like that however. Some command like tools add a porcelain option that produces output for scripting (ie no ansi color codes, easy to parse, etc). That works well too.

This is literally how all Linux and Unix CLI tools interoperate. Would be great to see wider adoption of something like PowerShell's ouput model.

The GPL license might be part of why this is done; running GPG in a separate process avoids infecting your code with its license.

This may or may not be true. Please ask your lawyer.

IANAL and I'm not saying this works from a legal standpoint (my understanding is it depends), I'm just arguing this is one reason why people might do this (run an executable and parse the output instead of just linking a library and passing proper data structures). I've seen it happen in another context.

This is uncommon and almost certainly specific to PGP. The PGP spec is large and complex. It's infinitely easier to use gpg(1) and parse its output than actually implementing PGP you need.

Elif?

I'm guessing they meant "Explain like I'm five". Though I usually see it abbreviated as ELI5.

I think it's worth mentioning that this is posted on NeoPG's site, which is a fork of GnuPG which seems to do really good work. I'm glad to see this happening since I'm using these tools and fixes are on the way :)

Specifically seems to be a fork providing a more concrete API, rather than GPG which has a CLI most people wrap.

Lots of bugs caused by that sort of thing, unfortunately it's all we have for GPG.

EDIT: It appears I was mistaken, the "GPGME" project also exists. I am not sure if that has some serious deficiencies that mean it's not used more often never the less, it's not the only option.

There is also GPGME.

If I were tasked with adding signature verification to an application I maintain and could only implement it by writing my own parser for GPG output, I think I would decide that something is catastrophically wrong with that design and I cannot support signature verification for the time being.

Am I being naive here?

Part 2: https://neopg.io/blog/enigmail-signature-spoof/

Part 3: https://neopg.io/blog/pass-signature-spoof/

Reply on news.ycombinator.com