Tampering with OpenPGP digitally signed messages by exploiting multi-part messages

The EFAIL vulnerability in the OpenPGP and S/MIME secure email systems, publicly disclosed yesterday, allows an eavesdropper to obtain the contents of encrypted messages. There’s been a lot of finger-pointing as to which particular bit of software is to blame, but that’s mostly irrelevant to the people who need secure email. The end result is that users of encrypted email, who wanted formatting better than what a mechanical typewriter could offer, were likely at risk.

One of the methods to exploit EFAIL relied on the section of the email standard that allows messages to be in multiple parts (e.g. the body of the message and one or more attachments) – known as MIME (Multipurpose Internet Mail Extensions). The authors of the EFAIL paper used the interaction between MIME and the encryption standard (OpenPGP or S/MIME as appropriate) to cause the email client to leak the decrypted contents of a message.

However, not only can MIME be used to compromise the secrecy of messages, but it can also be used to tamper with digitally-signed messages in a way that would be difficult if not impossible for the average person to detect. I doubt I was the first person to discover this, and I reported it as a bug 5 years ago, but it still seems possible to exploit and I haven’t found a proper description, so this blog post summarises the issue.

The problem arises because it is possible to have a multi-part email where some parts are signed and some are not. Email clients could have adopted the fail-safe option of considering such a mixed message to be malformed and therefore treated as unsigned or as having an invalid signature. There’s also the fail-open option where the message is considered signed and both the signed and unsigned parts are displayed. The email clients I looked at (Enigmail with Mozilla Thunderbird, and GPGTools with Apple Mail) opt for a variant of the fail-open approach and thus allow emails to be tampered with while keeping their status as being digitally signed.

Here’s what the original digitally signed email looks like in Apple Mail and Thunderbird. It’s terse, but not particularly problematic for the recipient. In both cases it is shown as being digitally signed (black tick in Apple Mail and green bar in Thunderbird).

Now let’s append some new content to significantly change the meaning of the email, change the subject (which is not signed in OpenPGP) and forward it onto the victim. Here’s what the modified version looks like.

In Apple Mail everything looks perfectly normal, properly digitally signed, but with the new text appended directly below the original message. In Thunderbird there’s a horizontal line separating the parts and the text in the green bar has changed. However I think it reasonable to expect that many email users would not notice this subtle change in security indicator, particularly because the “secure but with caveats” scenario is the one that usability research has shown to be the hardest to communicate effectively. Clicking on “Details” doesn’t give any indication as to which part(s) of the email are signed and which are not. This is all possible without resorting to HTML and other active content, unlike the EFAIL attack.

A safer option would be to fail-safe and only indicate an email is signed if the entire contents are, but this will interfere with legitimate ways in which email is processed. In fact, I first noticed the problem when I saw one of my digitally signed emails have text appended by Mailman, but still be treated as having a valid signature. Retrofitting security is hard, and characteristics like multi-part messages, intermediaries modifying text, the possibility of active content, and a massive legacy headache all make email pathologically difficult to secure. I’d love to be able to suggest something better, but while I think Signal is great it is not a drop-in replacement for all the ways that people use email (and it hasn’t had a good week either).

Nevertheless, it would have been good for the OpenPGP community to be more pro-active in defending against potential vulnerabilities. An effective defence against EFAIL attacks, the Modification Detection Code (MDC) has been part of the OpenPGP specification since 2000 and implemented in GnuPG for almost as long, but GnuPG leaves it to the discretion of email clients to check its status. (When a security mechanism is old enough to drink, I think it’s fine to make it mandatory.)

For the moment, because of the issues discussed in this post, as well as other security and usability problems, I don’t feel comfortable recommending using OpenPGP integrated with email clients. When email must be used, it’s less convenient but safer, and I think easier to understand, if the encryption and digital signatures are performed on files, which are then manually attached to emails after checking that they are properly encrypted. In the future I’d like a better answer than this and I’m hopeful that future research on usable security will help.

[If you’d like to try it out my demonstration for yourself, here’s an archive containing the original email and the modified one. Both are signed with a temporary key I set up for this purpose (with a 1 month validity), so you’ll need to import the corresponding public key is also in the archive. I haven’t tried other email clients so do let me know in the comments if you find out anything new.]

Update (2018-05-17): David McBride kindly tested in Evolution, and I think it did better than Thunderbird or Apple Mail, but I wouldn’t say it is safe. The signed part has a thin gold right-margin (it would have been green if the key was marked as trusted) and the the signature details are after the signed part, rather than at the top of the message. The margin indication is quite subtle so could be easily missed and the significance of the signature detail being in the middle of message is unlikely to be appreciated by the recipient. An attacker could increase the likelihood of success by prepending rather than appending new text (so the message would no longer be split by the signature details).