
SigSpoof: Spoofing signatures in GnuPG, Enigmail, GPGTools and python-gnupg - sphinxc0re
https://neopg.io/blog/gpg-signature-spoof/
======
mkesper
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.

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

~~~
bjpbakker
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.

~~~
chopin
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).

~~~
bjpbakker
> 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.

------
etu
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 :)

~~~
lathiat
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.

~~~
Boulth
There is also GPGME.

------
jancsika
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?

------
jwilk
Part 2: [https://neopg.io/blog/enigmail-signature-
spoof/](https://neopg.io/blog/enigmail-signature-spoof/)

Part 3: [https://neopg.io/blog/pass-signature-
spoof/](https://neopg.io/blog/pass-signature-spoof/)

