GnuPG and GnuPG clients unsigned data injection vulnerability

[Christoph Berg <cb@…>]

 Forwarding #413688 here as well...
 
 The attached mbox is available at http://bugs.debian.org/413688.
 
 ----- Forwarded message from J=F6 Fahlke <jorrit@jorrit.de> -----
 
 Date: Tue, 6 Mar 2007 17:01:33 +0100
 From: J=F6 Fahlke <jorrit@jorrit.de>
 Reply-To: J=F6 Fahlke <jorrit@jorrit.de>, 413688@bugs.debian.org
 To: Debian Bug Tracking System <submit@bugs.debian.org>
 Subject: Bug#413688: mutt: GnuPG and GnuPG clients unsigned data injectio=
 n
 	vulnerability
 
 Package: mutt
 Version: 1.5.13-1.1
 Severity: normal
 Tags: security
 
 [ Stealing the summary from GnuPGs announcement ]
 
 Gerardo Richarte from Core Security Technologies identified a problem
 when using GnuPG in streaming mode.
 
 The problem is actually a variant of a well known problem in the way
 signed material is presented in a MUA.  It is possible to insert
 additional text before or after a signed (or signed and encrypted)
 OpenPGP message and make the user believe that this additional text is
 also covered by the signature.  The Core Security advisory describes
 several variants of the attack; they all boil down to the fact that it
 might not be possible to identify which part of a message is actually
 signed if gpg is not used correctly.
 
 Core Securities advisory:
 http://www.coresecurity.com/?action=3Ditem&id=3D1687
 
 Announcement on the GnuPG mailinglist:
 http://lists.gnupg.org/pipermail/gnupg-announce/2007q1/000251.html
 
 I was able to verify that the second way of attack variant 2 decribed
 by Core Security does indeed work with mutt from testing.  A testcase
 is attached.
 
 MfG,
 J=F6.
 
 ----- End forwarded message -----
 
 Christoph
 --=20
 cb@df7cb.de | http://www.df7cb.de/
 
>Fix:
Unknown

[cb]

fixing category...

[brendan]

Must be properly assessed before 1.6.

[paul]

mbox file from the Debian BTS (apparently shows the problem).

[pdmef]

If I'm reading the links the right, we need to parse the status output of gnupg (once we know that we're actually using gnupg, not sure what the best/easiest/most reliable way to find out is) and buffer each new plain text part in a new tempfile since the status output tells us only afterwards whether the text was signed. After that we can compose a final tempfile to be displayed to the user with proper visual blocks indicating what is covered by gpg and what is not.

Since now the traditional pgp interface relies on commands and is more a pipe filter mechanism, this sounds quite difficult to implement cleanly since I think we'd need to apply the status parser on all gpg output we get.

Some more questions:

• as the commands are highly configurable, so what if a user doesn't have --status-fd in his settings? Should we enforce it?
• how do we determine we're actually using gpg? Apply a heuristic on the given pgp_*_command/pgp_good_sig setting? Apply a heuristic on the status output we're getting?