Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

neopg.io

Post reply on HN
Print view View original

1–10 of 20 posts

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

#3

Post by lathiat »

etu wrote: post #2

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.

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

#4

Post by 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.

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

#5

Post by Boulth »

lathiat wrote: post #3
etu wrote: post #2

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.

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

#6

Post by 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.

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

#7

Post by Karliss »

chopin wrote: post #4

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…

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.

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

#8

Post by bjpbakker »

chopin wrote: post #4

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…

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.

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

#9

Post by codeflo »

chopin wrote: post #4

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…

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

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

#10

Post by chopin »

bjpbakker wrote: post #8
chopin wrote: post #4

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…

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).
Post reply on HN