Sigspoof affects gpgbash?

Development
1

@Patrick I saw this attack discussed and was wondering if it applied to our package:

https://blog.patternsinthevoid.net/pretty-bad-protocolpeople.html

1 Like
2

https://blog.patternsinthevoid.net/pretty-bad-protocolpeople.html

My python-gnupg module isn’t vulnerable to SigSpoof, for several reasons:

–no-options is passed by default. So if you’ve got something stupid in your gpg.conf file, you’ll still be fine while using my Python module.

Same for gpg-bash-lib. Always using --no-options and separate config directory.

–verbose is not passed. This means that my library doesn’t have to wade throught a mixture of strange stderr and GnuPG status-fd messages on the same file descriptor. You could pass --verbose to it manually, as it is in the list of allowable, whitelisted options, but the exploit still won’t work, which brings us to our next point:

Same for gpg-bash-lib. Not using --verbose.

All inputs to, and outputs from, the gnupg binary are sanitised and then forced to conform to whitelists. This means that, even if you did pass --verbose manually, the filename trick won’t work because there’s no way to safely sanitise a filename, because filenames may be arbitrary bytes.

Not implemented.

For developers
…
Or, the --status-file FILE option could be used to direct the status lines to a temporary file.

This has always been the case.

https://lists.gnupg.org/pipermail/gnupg-announce/2018q2/000425.html

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. The log output defaults to stderr (2) but may be a different if the option --logger-fd is used.

They don’t mention --status-file explicitly but it is as good s "dedicated file descriptor with --status-fd ", i.e. log and status fd messages are separate.

It’s fixed in Debian.

So either way we’re good.

1 Like