Weblog entry #108 for dkg

Inline-PGP considered harmful
Posted by dkg on Mon 24 Feb 2014 at 02:09
We changed the default PGP signatures generated by enigmail in debian from Inline PGP to PGP/MIME last year, and the experiment has gone well enough that we're now using it in jessie and wheezy (where it arrived as part of a security update to make the extension work with the security-updated icedove package).

After having several people poke me in different contexts about why inline cleartext PGP signatures are a bad idea, i got sufficiently tired of repeating myself, and finally documented some of the problems explicitly.

The report includes a demonstration of a content-tampering attack that changes the meaning of a signed inline-PGP message without breaking the signature, which i first worked out on the notmuch mailing list, but hadn't gotten around to demonstrating until recently.

The attack is demonstrated against clearsigned messages, but also works against inline encrypted messages (but is harder to demonstrate since a demonstration would require sharing secret key material for the decryption step).

Please don't generate Inline-PGP messages. And if you must parse and accept them, please consider carefully the risks you expose your users to and think about ways to mitigate the problems.

 

Comments on this Entry

Posted by Anonymous (201.124.xx.xx) on Mon 24 Feb 2014 at 03:02
Of course, I'm thinking about RT's habit of breaking signatures, as it mangles the message. And yes, in keyring-maint we have several requests where the signature breaks due to encoding issues.

What would be your recommendation on this?

[ Parent | Reply to this comment ]

Posted by dkg (212.110.xx.xx) on Mon 24 Feb 2014 at 04:28
[ Send Message | View dkg's Scratchpad | View Weblogs ]
I'd say RT needs to step up its game in dealing with MIME parts. As i understand it, RT is not checking signatures itself -- the problem is that it is mangling the PGP/MIME-signed messages it receives before re-sending them. PGP/MIME-signed messages are signed using the multipart/signed Content-Type. RT's behavior is a straightforward violation of section 2.1 of RFC 1847, which states:
2.1 Definition of Multipart/Signed

   (1)  MIME type name: multipart

   (2)  MIME subtype name: signed

   (3)  Required parameters: boundary, protocol, and micalg

   (4)  Optional parameters: none

   (5)  Security considerations: Must be treated as opaque while in
        transit

By not treating the content of a multipart/signed MIME part as opaque (by modifying it in transit), RT fails to live up to this 18-year-old standard. I don't see the bug reported in the debian BTS, and the closest upstream bug i was able to find is not explicitly about multipart/signed and its consequences.

It's not clear to me how to even report a bug against RT4 using the upstream RT instance, sadly. Is there a concrete report where the shortcoming is well-documented, with a simple example case?

[ Parent | Reply to this comment ]

Posted by Anonymous (94.198.xx.xx) on Wed 26 Feb 2014 at 09:27
You are wrong in most parts, and here I will say why:

Boundary spoofability ⇒ clearly a client problem, not a problem of Inline PGP per se.

Poor handling of non-ASCII text ⇒ this is one of the most infamous myths about PGP. Actually, PGP/MIME in nōn-opaque mode is the one at harm here, not Inline PGP, because Inline PGP applies strictly *after* the MUA processing the incoming message, and strictly *before* the MUA ever gets to see the messsage body. A correct way to do Inline PGP, for example (and the one I’m using myself) is to compose a message in an editor such as https://www.mirbsd.org/jupp.htm that allows piping it through external commands (or saving it to a file then doing that from the command line), followed by running “gpg --clearsign” or “gpg -seatr 12345678 -r 9ABCDEF0” on it, and only then passing the result to the MUA. Inline PGP *may not* be handled without an MUA first parsing the message, and most specifically it *may not* be run on the raw RFC822 text. This makes Inline PGP robust even against MTAs (correctly!) recoding the message e.g. from 8BITMIME to quoted-printable.

Poor handling of non-text/plain messages ⇒ Actually, text/html or RTF eMails are Bad™, so I don’t think this is a problem.

Line-wrapping issues ⇒ only applies to “format=flawed” (actually “flowed”) messages, and only to those where there is a literal space at the end of the line. f=f is broken anyway and ought to be disabled… and it just *must* be disabled when dealing with PGP. This is a property of the sending MUA, so the sending party is responsible for configuring their MUA properly when using PGP.

Poor handling of Multipart messages (including attachments) ⇒ Agreed. There _is_ “partitioned” which deals with every part separately. Also, it’s possible (still!) to use uuencode for attachments, which works decently with Inline PGP, even though it has a certain yuck factor, and many people and MUAs do not know how to deal with them any longer.

Message tampering through header substitution ⇒ This is basically a repeat of the first part. By defining what precisely is protected and what isn’t, this can be defined to not be a part of the problem realm. (Do note that PGP/MIME does not secure *all* headers either.) The multipart problem is related to this one, too. “Inline-PGP-signed messages derive their Content-Type and Content-Transfer-Encoding from the headers of the associated message.” is also only correct partially… PGP framing also has got a charset indicator. (Also, see what I said about MUA decoding.) But I’d agree saying that anything not using UTF-8 is suspect. (Enigmail is notorious for using latin9, though.) The thing to consider here is that PGP/MIME focuses on eMail, whereas Inline PGP operates on files/bytestreams, indeed (which is why there’s a charset indicator on the PGP message, too). MUAs doing Inline PGP correctly (point #1) would probably need to decode the PGP part, then iconv it from the PGP charset to the message charset, then add indicators denoting which parts are signed/encrypted or not (KDEPIM does this nicely with colours), then display that. And having diverging charsets is where clearsign breaks its leaky abstraction, granted.

But PGP/MIME is worse in so many regards: it needs very tight MUA integration (I tried to write an MDA that transparently handles decrypting PGP/MIME messages on delivery to me, when I was on a job that forced me to deal with a PGP/MIME-using mailing list, and let me tell you it’s full of potholes) and doesn’t fix all of the above problems either. Its abstraction is just as leaky, it just has the problems in different places – not less difficult to spot, either. Also, PGP/MIME is often broken by things such as ticket systems or mailing list managers doing slightly-incorrect things, and PGP/MIME nōn-opaque is most definitely broken by MTAs doing correct, RFC-mandated, things (see above).

//mirabilos

[ Parent | Reply to this comment ]

Posted by mcortese (85.158.xx.xx) on Mon 3 Mar 2014 at 17:56
[ Send Message | View Weblogs ]
Poor handling of non-text/plain messages ⇒ Actually, text/html or RTF eMails are Bad™, so I don’t think this is a problem.
Aaah, I wish all problems could be dismissed by simply declaring the underlying system Bad™ and thus not worth fixing!

[ Parent | Reply to this comment ]