https://efail.de/#disclousure lists Evolution as affected regarding S/MIME. 
It also lists Evolution as unaffected regarding GPG.

The "First contact" on 2018-02-19 probably took place in bug 793594.
It was (partially???) marked as a duplicate of bug 793449 which needs to get fixed in underlying library: https://bugs.webkit.org/show_bug.cgi?id=182924
Milan might want to double-check this again - he knows best.

In general: Short-term mitigation: Make sure that encrypted mails are not able load remote content (no clickable links, no option to load images, maybe even show as plaintext by default).

Hi, my two cents on this (I'm following this for the Debian Security Team).

I don't have access to bug #793594 so I'm unsure what's the content there, but bug #793449 is about DNS prefetching, as well as https://bugs.webkit.org/show_bug.cgi?id=182924. So to me this is about the backchannel H3 note in the Efail paper (Table 5, p. 20 https://efail.de/efail-attack-paper.pdf#appendix.D).

This is then not about the underlying issue with S/MIME (Table 4, p. 11 https://efail.de/efail-attack-paper.pdf#table.caption.11), where it's possible to blind-modify the content without detection (because of lack of authenticated encryption in S/MIME). It's supposedly not possible to fix this without touching the standard, but Claws and Mutt are marked as not vulnerable (I guess because the decryption is not native but happens in a separate process but I'm unsure exactly why).

With respect of the "Direct Exfiltration", there is no problem in evolution, because it parses the message into separate parts first and only then traverses them one-by-one. There is no content merging done as suggested on their site in evolution, each part has its own iframe in WebKitGTK+, which do not know about each other.

The DNS prefetching is related, because it can do the server query without user intervention. Evolution does disable DNS prefetching for years, but it turned out that the HTML content could enable it in WebKitGTK+, for which is the WebKit bug.

The CBC/CFB attack could inject the HTML code to enable DNS prefetching and then add there some <link>-s of CSS or anything, which would contain the decrypted message text. Again, without user even knowing it. It's not the case with patched WebKitGTK+. And with disabled remote content download in Evolution it's all fine here for other links/anchors/images as well. Evolution doesn't validate the links, users can still click on them, but, from my point of view, it's okay. The responsibility is just passed to the user.

As the paper itself says, there is nothing the clients can do about CBC/CFB attack, the change is supposed to be done in the standard (and underlying libraries, which in case of Evolution, as of today, means gpg and NSS).

I'd be happy to add any arguments/code into the Camel to avoid these attacks, but I do not know gpg nor NSS that well to know whether there are any such arguments/flags/whatever to be passed. It would be nice to hear a voice from the maintainers/developers of these to know for sure.

I think it might be worth trying to harden the MIME code when handling mixed (plaintext/encrypted content), but I'm unsure how.

It might be worth checking how Evolution handles https://www.benthamsgaze.org/2018/05/15/tampering-with-openpgp-digitally-signed-messages-by-exploiting-multi-part-messages/ for example.

Created attachment 372088 [details]
Screenshot comparison

corsac: Thanks for the testcase!

evolution-3.28.2-1.fc28.x86_64
evolution-data-server-3.28.2-1.fc28.x86_64
webkit2gtk3-2.20.2-1.fc28.x86_64
gnupg2-2.2.6-1.fc28.x86_64
gnupg-1.4.22-6.fc28.x86_64
nss-3.36.1-1.1.fc28.x86_64

1. Downloaded https://www.benthamsgaze.org/wp-content/uploads/2018/05/emailmodification.zip and extract
2. /usr/bin/gpg2 --import ~/gnomebug796135/publickey.asc
3. Start Evolution
4. Import original test message "orig.eml"
5. See "Valid signature but cannot verify sender" GPG info bar
   displayed below the message
6. Import modified/tampered test message "modified.eml"
7. See "Valid signature but cannot verify sender" GPG info bar
   below the original message part; see the modified message part
   displayed below that GPG information bar.
   Nothing that would allow me to realize that the recipient
   or the subject line got modified.

(In reply to André Klapper from comment #5)
> Created attachment 372088 [details]
> Screenshot comparison

> 7. See "Valid signature but cannot verify sender" GPG info bar
>    below the original message part; see the modified message part
>    displayed below that GPG information bar.
>    Nothing that would allow me to realize that the recipient
>    or the subject line got modified.

I'm not sure it's even possible to detect subject/recipient modifications since I don't think they're inside the signed part. It's a real problem but it's more linked to email than anything else.

The signed part and the unsigned part are visible if one looks for it, but indeed it might not be really visible for an untrained user.

(In reply to André Klapper from comment #5)
> 1. Downloaded
> https://www.benthamsgaze.org/wp-content/uploads/2018/05/emailmodification.
> zip and extract

It's not what the EFAIL is about. EFAIL is about having encrypted message and letting this encrypted message decrypt by the recipient and expose what it was. The CBC/CFB kind of allows to modify one encrypted message and (prepend?) to it another encrypted message, where the receiver will not notice the difference and will decrypt the blob as it was created as such by the sender. There is not said anything about encrypted&signed, which might be one way to detect issues on both PGP and S/MIME.

GPG is safe though, see [1].

It's harder with S/MIME. I do not have access to [2], which may or may not contain information for NSS, because it's what Thunderbird uses for S/MIME for sure and Evolution uses NSS as well. If you have someone from NSS knowledgeable folks to ask, whether there's any way on the client side to do anything about it, even a negative answer is a good answer, then it'll help.

>   Nothing that would allow me to realize that the recipient
>   or the subject line got modified.

As Corsac said, if you know what to look for, then you are fine. Evolution highlights which part of the text had been signed and not modified and which not.

This kind of modification is common with mailing lists, which add their footer to each message. Some are smart, some are dumb. There are bugs about it here (I recall one where the mailman doesn't respect base64 encoding of the part and appends at the end of the text/plain part its footer, which shows garbage in the GUI).

[1] https://lists.gnupg.org/pipermail/gnupg-users/2018-May/060334.html
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=1411592

There's a bit of a contradiction here, on the one hand I hear there's no issue, but bug #1411592 is still not publicly accessible, meaning I guess at least that investigation is ongoing.

It would be good to have access to this bug report if really there's no concern. I use S/MIME GPG a lot, the EFAIL website says evolution is vulnerable, there's a hidden bug report and here I hear it's all fine.

This is not exactly the sort of communication I would expect from a big open source project after so much time has elapsed.

No offence meant to the very helpful people who took the time to reply to this thread of course!

Do you use S/MIME, or GPG, or both? Those are two different things.

When you encrypt, do you also sign the message? It's the way to ensure the message didn't change. It's not clear to me from the efail web page whether they can abuse S/MIME with encrypt only or also with encrypt&sign, but it seems to me they talk about encrypt only.

The bug you mentioned is a Mozilla bug, not Evolution, neither GNOME. I looked into the changes on the Thunderbird side and they did not do anything with NSS calls as such, thus it's solely Thunderbird bug. [3]

The way Evolution is vulnerable with the S/MIME thing, from my point of view, is that it won't notice the encrypted blob had been modified, because the underlying library (NSS) would not notice it as well (similarly as other libraries, it's due to the S/MIME standard, as had been said both on the efail page and here as well). The difference from Thunderbird is that Evolution won't expose the decrypted data to the public, unless users have it set to download remote content. It wasn't the case in the Thunderbird. And as long as Evolution won't expose encrypted data by GPG, it cannot expose the data encrypted by S/MIME - I'm still talking about DNS prefetching and remote content in HTML messages.

[3] https://hg.mozilla.org/releases/comm-esr52/rev/886b0e10bafa

Apologies, I meant bug 793594, not the mozilla one.

I use S/MIME and this is what they say regarding signatures: 
https://efail.de/#will-signatures

If efail.de is unclear you will have to contact the maintainers of efail.de, I'm afraid. Or I am not sure / don't understand what you are asking for... :-/

(In reply to François Guerraz from comment #10)
> I use S/MIME and this is what they say regarding signatures: 
> https://efail.de/#will-signatures

Ah, I missed that. Quote from the web site:

>> Will signatures prevent these attacks?
>>
>> No. PGP and S/MIME emails are displayed in the email program independently
>> of whether or not they are signed or whether an existing signature is valid
>> or not. Even if signatures did matter: an attacker can copy the altered
>> ciphertext into a separate email and create a valid signature under his own
>> name.

While the answer can apply in general, it is not correct for Evolution. Again (this is kind of going into circles) users of Evolution have under control whether they download remote content or not and the default after install is 'never'. For the DNS prefetching it requires changes in the WebKitGTK+. With this on mind, even if evolution shows the decrypted message content it won't expose it anywhere.

With signatures, Evolution does check whether the signer's email address and the sender's email address match and if not then it notifies about it (there are bug reports about false positives here). Thus when the attacker signs with his certificate, then you'll be notified.

But more importantly (and I can be wrong here, thus this is my personal opinion), the message is always first signed and then encrypted, which means that the encrypted blob contains the signature. Evolution parses each part separately, thus you'd see one part signed with the original author and another part signed with the attacker, eventually one with sender's email as trusted and one as untrusted (the attacker's certificate will not be trusted to be from the sender, because it'll be seen for the first time).

I mean, evolution will always give you the feedback according to its settings and it's up to the user to read it and to decide what to do according to the given feedback. Other mail clients can work differently.

I think there's nothing more to say or do here, thus I'm closing this bug report.