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

11–20 of 20 posts

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

#11

Post by mkesper »

codeflo wrote: post #9
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.

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

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

#12

Post by FredFS456 »

chopin wrote: post #10
bjpbakker wrote: post #8

Earlier quoted context omitted.

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 c…

awscli tools can generally do so.

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

#13

Post by beefhash »

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…

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.

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

#14

Post by bjpbakker »

chopin wrote: post #10
bjpbakker wrote: post #8

Earlier quoted context omitted.

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 c…

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

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

#15

Post by evancox100 »

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.

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.

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

#17

Post by jwilk »

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…

Elif?

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

#18

Post by __david__ »

jwilk wrote: post #17
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…

Elif?

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

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

#19

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

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

#20

Post by codeflo »

mkesper wrote: post #11
codeflo wrote: post #9

Earlier quoted context omitted.

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