Bug 20801 - Pine/GPG allows for signature spoofing
Pine/GPG allows for signature spoofing
Status: CLOSED WONTFIX
Product: Red Hat Linux
Classification: Retired
Component: pine (Show other bugs)
7.0
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Mike A. Harris
David Lawrence
: Security
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2000-11-13 17:47 EST by Yaron Minsky
Modified: 2007-04-18 12:29 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2000-11-19 19:18:51 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Yaron Minsky 2000-11-13 17:47:06 EST
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.
Comment 1 Daniel Roesen 2000-11-13 17:56:34 EST
assigning "Severity: security"
Comment 2 Daniel Roesen 2000-11-13 18:27:05 EST
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.
Comment 3 Mike A. Harris 2001-01-28 13:54:10 EST
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...
Comment 4 Stiphane Doyon 2001-01-30 20:06:08 EST
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!

Note You need to log in before you can comment on or make changes to this bug.