Security Vulnerability: Faulty GPG Signature Checking

[Jason A. Donenfeld]

Hey list,

After discussing pass and GPG with Marcus Brinkmann at FOSDEM this
year, and then witnessing the amazing bugs in Enigmail a while back,
Marcus went and had a look at how our shell script is actually dealing
with GPG output. He discovered (1) that our parsing of gpg command
line output with regexes isn't anchored to the beginning of the line,
which means an attacker can generate a malicious key that simply has
the verification string as part of its username, which fixed in pass
1.7.2. This has a number of nasty consequences: a) an attacker who
manages to write into your ~/.password-store and also inject a
malicious key into your keyring can replace your .gpg-id key and have
your passwords encrypted under additional keys; b) if you have
extensions enabled (disabled by default), an attacker who manages to
write into your ~/.password-store and also inject a malicious key into
your keyring can replace your extensions and hence execute code. This
has been assigned CVE-2018-12356.

Marcus also points out two secondary problems related to integrity.
The first secondary problem (2) is that while we try to preserve gpg's
exit code, in case of a decryption failure, the gpg tool has a
deficiency that it always writes to stdout before verification, which
is mitigated in pass 1.7.2 by simply buffering the output ourselves
(ugh). The second secondary problem (3) is that pass does not sign its
files, which means an attacker who manages to write into your
~/.password-store and also inject a malicious key into your keyring
can display the wrong password. Problem (3) is not a new finding at
all for pass, and I group it together with the well-known related
aspect, which is that the directory tree itself doesn't have any
integrity: you can add, remove, and rename files trivially, if you're
not using git with commit signing. Pass's direct use of GPG has always
focused on secrecy without a lot of focus on authenticity, blaming the
GPG tooling again. Our recommendations for authenticity and integrity
continue to be to enable git commit signing, which pass has built-in
support for.

One way to add this directly to pass without relying on git to handle
it for us is by adding signatures to each file, which I've long
resisted for a variety of reasons, both due to the GPG tooling
boogieman, as well as semantic issues with then verifying against user
ids that have been removed from .gpg-id. Perhaps a different way would
be for pass to use its own keyring, rather than the default ~/.gnupg
keyring; we can discuss ideas like these for 1.8. Either way, if
you're managing and sync'ing your password store using git, you really
should be signing those git commits. Perhaps we can also consider
_enforcing_ git signatures.

I remember Marcus and my funny conversation at FOSDEM, during which he
asked me my ideas on the GPG interface and what it provides and what
pass might need from it, which provoked what was evidently a lot of
pent-up frustration in me with the command line tools. I recall
mentioning how pass is this ever-sprawling bash script filled with
impossible to understand regular expressions, because GPG doesn't
provide a more precise interface for verifying and extracting the
information we need. I'm quite happy he looked into it for us.

There are two reasons why my presence on this list is fairly minimal
these days: I'm extremely hesitant to add new junk to pass, as I don't
think feature bloat is actually a real feature with tools like this,
which are supposed to be simple, and I've been fantasizing about some
rearchitecting for a long time. One plan for that would be to simply
use a cleaner subset of bash -- no use of sed, only bash regular
expressions. The other would be to rewrite this in a real programming
language and link to the gpgme library, which ostensibly gives us
fine-grained verification and checking. The argument against the
latter has been that the appeal of pass is that it's "just" a simple
bash script; however, as Marcus' findings have pointed out, is it
actually possible to use the GPG command line utility from bash in a
way that is both safe and simple? Seems like it might be a "choose
one" situation, and the result will always be fragile at best. On the
other hand, the prospect of investing energy into byzantine interfaces
like GPG seems perhaps misguided, and we might consider alternatives.
Either way, I will do some significant reworking for pass 1.8, to
cleanup a rather elementary script into something as robust as
possible.

So with that said, please upgrade to pass 1.7.2, and don't hesitate to
email me directly if you find additional issues.

Regards,
Jason