Re: how bad is it?
The GnuPG people are annoyed, according to a colleague who is on the mailing list. They weren't informed in advance (although Werner Koch managed to view the report). It seems to be a well known problem with HTML emails and clients (MUAs) that automatically deference external links - so the "problem", according to them is with the way the email clients work.
Edit: edited to clean up line-breaks!
https://lists.gnupg.org/pipermail/gnupg-users/2018-May/060317.html
Werner saw a preprint of this paper some time ago. I saw it recently. Patrick Brunschwig of Enigmail saw it. None of us are worried. Out of respect for the paper authors I will skip further comment until such time as the paper is published.
It would've been nice if EFF had reached out to us for comment, rather than apparently only talking to the paper authors. We hope they'll reach out next time.
https://lists.gnupg.org/pipermail/gnupg-users/2018-May/060315.html
Some may have noticed that the EFF has warnings about the use of PGP out which I consider pretty overblown. The GnuPG team was not contacted by the researchers but I got access to version of the paper related to KMail. It seems to be the complete paper with just the names of the other MUAs redacted.
Given that the EFF suggests to deinstall GpgOL, we know tha it is not vulnerable; see see https://dev.gnupg.org/T3714.).
Here is a response I wrote on the weekend to a reporter who inquired on this problem.
=============
The topic of that paper is that HTML is used as a back channel to create an oracle for modified encrypted mails. It is long known that HTML mails and in particular external links like <img href="tla.org/TAG"/> are evil if the MUA actually honors them (which many meanwhile seem to do again; see all these newsletters). Due to broken MIME parsers a bunch of MUAs seem to concatenate decrypted HTML mime parts which makes it easy to plant such HTML snippets.
There are two ways to mitigate this attack
- Don't use HTML mails. Or if you really need to read them use a proper MIME parser and disallow any access to external links.
- Use authenticated encryption.
The latter is actually easy for OpenPGP because we started to use authenticated encryption (AE) since 2000 or 2001. Our AE is called MDC (Modification detection code) and was back then introduced for a very similar attack. Unfortunately some OpenPGP implementations were late to introduce MDC and thus GPG could not fail hard on receiving a mail without an MDC. However, an error is returned during decrypting and no MDC is used:
gpg: encrypted with 256-bit ECDH key, ID 7F3B7ED4319BCCA8, created 2017-01-01
"Werner Koch <wk at gnupg.org>"
[GNUPG:] BEGIN_DECRYPTION
[GNUPG:] DECRYPTION_INFO 0 7
[GNUPG:] PLAINTEXT 62 1526109594
[GNUPG:] PLAINTEXT_LENGTH 69
There is more to life than increasing its speed.
-- Mahatma Gandhi
gpg: WARNING: message was not integrity protected
[GNUPG:] DECRYPTION_FAILED
[GNUPG:] END_DECRYPTION
When giving a filename on the command line an output file is even not created. This can't be done in pipe mode because gpg allows to process huge amounts of data. MUAs are advised to consider the DECRYPTION_FAILED status code and not to show the data or at least use a proper way to display the possible corrupted mail without creating an oracle and to inform the user that the mail is fishy.
For S/MIME authenticated encryption is not used or implemented in practice and thus there is no short term way to fix this in S/MIME except for not using HTML mails.
The upshot of this is that OpenPGP messages are way better protected against such kind of attacks than S/MIME messages. Unless, well, the MUAs are correctly implemented and check error codes!
Biting the hand that feeds IT
