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 _______________________________________________ Password-Store mailing list [email protected] https://lists.zx2c4.com/mailman/listinfo/password-store
