Red Hat Bugzilla – Bug 20801
Pine/GPG allows for signature spoofing
Last modified: 2007-04-18 12:29:49 EDT
Pine's GPG setup has a fatal UI security flaw. In particular, the only way that Pine signals that a give message is signed is with a piece of text of the following form: ---------------------------------------------------------------------- gpg: Signature made Mon 13 Nov 2000 05:43:40 PM EST using DSA key ID 1F2C47C gpg: Good signature from "Yaron M. Minsky <yminsky@alumni.princeton.edu>" gpg: aka "Yaron M. Minsky (Cornell University Computer Science Department) <yminsky@cs.cornell.edu>" ---------------------------------------------------------------------- Unfortunatly, such a text can simply be stuck at the end of an email. There is basically no way of distinguishing this from a message which has truly been signed. (you might think the absence of the quick flash of the screen as GPG interpretes the message would tell you the difference. It doesn't. First of all, if the message is encrypted, then GPG will run to do the decryption, even though it isn't used to verify the signature. There are a few ways of fixing this bug: - display the signature in a different color one that isn't used for anything else. - Have the signature text include a nonce: some random string, written prominently, that is chosen randomly at the time of the signature verification. this text should also be shown somewhere that can't be forged by an incoming message, for instance, at the beginning of the message, before the headers appear. The color solution is better because of its clarity. Something like the latter solution should probably also be included for people who don't have or use color.
assigning "Severity: security"
If I'm not mistaken, mutt is also vulnerable to this problem as mutt colorizes "[---- whatever ----]" lines contained in the message body as if they were from mutt's MIME part parser. Will verify that tomorrow.
I have looked into this problem and have decided that there is no solution possible. 1) Any solution involving changing colors does not work because that would restrict the feature to people using color enabled terminals. This is not acceptable. 2) The method used for gpg/pgp checking in PINE uses PINE filters to do the magic, and is thus subject to the limitations of PINE's filter mechanism. Thus the existing pgppine filter can not IMHO be changed in any way to be secure other than completely reimplementing it from scratch as an interactive application. Thus fixing the problem, yet retaining the existing call via pine filters is not possible. 3) Another option is to add the functionality directly into PINE. This is the "proper" solution IMHO as it can be done securely, and is where the support for this sort of thing belongs IMHO. Unfortunately, this means making major enhancement modifications to PINE. If PINE was GPL licenced, or some other open source / free software licence, this would be entirely possible. Unfortunately, the licencing of PINE is restrictive, and not open source friendly. As such, this is not a realistic alternative either - at least not for Red Hat to undertake. 4) There are no known complaints of people actually doing any "spoofing" so I don't see it as a severe problem. So, as it stands, I cannot fix this problem due to the above reasons. If it becomes a large enough problem for people, and a lot of complaints are filed, I will remove pgppine solely to solve the problem at the unfortunate expense of lost functionality. That is about all I can do...
Case 2) in the previous comment suggest one patch would be to "completely reimplementing it from scratch as an interactive application.". Seems to me this could be done not so drastically. My own quick hack/fix was the following: in /usr/bin/pinegpg: the code under case *gpg-check): do something like: #clear 1>&2 echo "--------" 1>&2 gpg $* | awk '{print gensub("\r", "", "")}' n=$? echo "--------" 1>&2 read < /dev/tty if [ $n = 0 ]; then r=0; fi This would display the gpg result before showing the message, and wait for a key press before showing the message. Not ideal, but better than nothing for me. It is true that this sort of security should be handled inside pine: f.e. attachments are not signed or encrypted, and this fact is easily overlooked!