Is mu/mu4e affected by EFAIL attack on OpenPGP and S/MIME?

[Mekeor Melire]

"EFAIL describes vulnerabilities in the end-to-end encryption
technologies OpenPGP and S/MIME that leak the plaintext of encrypted
emails." (https://efail.de/) EFAIL has been published yesterday (14th
May 2018).

Common mail-clients like Thunderbird, Apple Mail and Microsoft Outlook
are affected. That's why the Electronic Frountier Foundation (EFF)
recommends to disable PGP-encryption/decryption for users of them.

Is Mu / Mu4e affected by this vulnerability?

[Arne Köhn]

Am 15. Mai 2018 17:49:53 MESZ schrieb Mekeor Melire <mekeor...@gmail.com>:
>"EFAIL describes vulnerabilities in the end-to-end encryption
>technologies OpenPGP and S/MIME that leak the plaintext of encrypted
>emails.
>

>Is Mu / Mu4e affected by this vulnerability?

No because it does not load remote images by default. BTW, neither is the current Thunderbird+Enigmail.

[Mekeor Melire]

But in fact, it is also possible to exploit EFAIL without HTML.

"[T]here are other possible backchannels in email clients which are not
related to HTML but these are more difficult to exploit."
(https://efail.de/#mitigations)

The chapters "6.2 S/MIME specific backchannels" and "6.3 OpenPGP
specific backchannels" of the official technical paper
(https://efail.de/efail-attack-paper.pdf) describe those methods that
don't require HTML. Although it requires some cryptographic
understanding, it's quite possible, as far as I understand.

That's also why Thunderbird+Enigmail is still vulnerable, AFAIU.

[Charles-H. Schulz]

Hello,

It is my understanding that EFail would primarily affect the cryptographic implementations of PGP within email clients. But mu relies on the GPG implementation of Emacs. Also when sending message it generally relies on Emacs's message mode. 

So perhaps the question is not so much related to mu4e as it should be concerning Emacs's PGP implementation and the MUAs running on Emacs in general...

Hope this helps,

Charles.

--
You received this message because you are subscribed to the Google Groups "mu-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mu-discuss+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Mekeor Melire]

Charles-H. Schulz <charles....@gmail.com> writes:

> It is my understanding that EFail would primarily affect the cryptographic
> implementations of PGP within email clients. But mu relies on the GPG
> implementation of Emacs.

"GPG implementation of Emacs" is a bit misleading phrasing. Emacs does
not implement GPG. Emacs has a wrapper around GPG, I'd guess.

> Also when sending message it generally relies on Emacs's message mode.

Right, but EFAIL does not happen while sending a message but it happens
while decrypting an encrypted message.

> So perhaps the question is not so much related to mu4e as it should be
> concerning Emacs's PGP implementation and the MUAs running on Emacs in
> general...

I agree that mu4e might be unblamable. But I'm not fully technically
convinced at this moment.

[Mekeor Melire]

This is my current understanding of why EFAIL usually does not affect
Mu4e much. We have the following scenarios:

(1) The incoming mail uses HTML.

(1.a) As Arne Köhn already pointed out, mu4e “does not load remote
images by default”. Does it not load ANYTHING remote (apart from images)
by default? If it does, Mu4e is might be affected by EFAIL, by default.
Otherwise we're good by default.

(1.b) If you configured Mu4e/Emacs to load remote HTML images/stuff, the
incoming mail might exploit EFAIL, AFAIU.

(2) The incoming mail uses S/MIME encryption. In Mu4e, “[c]urrently,
decryption and signature verification only works for PGP/MIME;
inline-PGP and S/MIME are not supported.“
(https://www.djcbsoftware.nl/code/mu/mu4e/Signing-and-encrypting.html)
So, in this case, the incoming mail does not affect Mu4e, AFAIU.

(3) The incoming mail uses OpenPGP/MIME
(https://tools.ietf.org/html/rfc2440 &
https://tools.ietf.org/html/rfc3156), the incoming mail might try to
exploit EFAIL through "OpenPGP specific backchannels". "This can
potentially be abused by mal- leability gadgets to leak four bytes of
plaintext." (https://efail.de/efail-attack-paper.pdf) Four bytes is not
much, AFAIU. (AFAIU, it might be the `append_sexp_parts` function in the
source code of Mu which might be responsible for this issue:
https://github.com/djcb/mu/blob/b9d2046a6e037bf8095e8071f2365a5643a2a4a9/lib/mu-msg-sexp.c#L428-L429).

--
mekeor ~ EDD3 DFFA 76F6 11C0 145F 9A99 AC85 BAD8 A2F8 C868

[Charles-H. Schulz]

Hello Mekeor,

2018-05-16 1:17 GMT+02:00 Mekeor Melire <mekeor...@gmail.com>:

Charles-H. Schulz <charles....@gmail.com> writes:

> It is my understanding that EFail would primarily affect the cryptographic
> implementations of PGP within email clients. But mu relies on the GPG
> implementation of Emacs.

"GPG implementation of Emacs" is a bit misleading phrasing. Emacs does
not implement GPG. Emacs has a wrapper around GPG, I'd guess.

I think you may be right here. To be honest I still do not understand how Emacs actually handles GPG. If it's a wrapper then it sure is a PITA to use. But I digress...

 

> Also when sending message it generally relies on Emacs's message mode.

Right, but EFAIL does not happen while sending a message but it happens
while decrypting an encrypted message.

That does not really change my point: mu4e does not decrypt encrypted messages if I understand this correctly: it's Emacs that does it through its implementation/wrapper of GPG. So here the point is to check if this component is affected and for each user to ensure they use a reasonably recent version of GPG on their system.

> So perhaps the question is not so much related to mu4e as it should be
> concerning Emacs's PGP implementation and the MUAs running on Emacs in
> general...

I agree that mu4e might be unblamable. But I'm not fully technically
convinced at this moment.

See my answer above: it all boils down to how GPG is handled. I do not think mu4e calls GPG directly, nor does it implement a tool to let the user interact with it. It relies on Emacs' own mechanism for that. But maybe (?) there's a separate attack channel that is accessible through mu4e in the way it calls Emacs' own implementation. That would be the worst possibility although my somewhat wild guess is that it's rather far-fetched.

Best,

Charles.

 

> Le mar. 15 mai 2018 à 20:05, Mekeor Melire <mekeor...@gmail.com> a
> écrit :
>
>>
>> Arne Köhn <ar...@chark.eu> writes:
>>
>> > Am 15. Mai 2018 17:49:53 MESZ schrieb Mekeor Melire <
>> mekeor...@gmail.com>:
>> >>
>> >>Is Mu / Mu4e affected by this vulnerability?
>> >
>> > No because it does not load remote images by default. BTW, neither is
>> > the current Thunderbird+Enigmail.
>>
>> But in fact, it is also possible to exploit EFAIL without HTML.
>>
>> "[T]here are other possible backchannels in email clients which are not
>> related to HTML but these are more difficult to exploit."
>> (https://efail.de/#mitigations)
>>
>> The chapters "6.2 S/MIME specific backchannels" and "6.3 OpenPGP
>> specific backchannels" of the official technical paper
>> (https://efail.de/efail-attack-paper.pdf) describe those methods that
>> don't require HTML. Although it requires some cryptographic
>> understanding, it's quite possible, as far as I understand.
>>
>> That's also why Thunderbird+Enigmail is still vulnerable, AFAIU.

--
You received this message because you are subscribed to the Google Groups "mu-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to mu-discuss+unsubscribe@googlegroups.com.

[Charles-H. Schulz]

By the way, this is the GnuPG team official statement. https://lists.gnupg.org/pipermail/gnupg-users/2018-May/060334.html

I think they make good points but are somewhat optimistic in their assessment of the problem...

Best,

Charles.

[Arne Köhn]

Charles-H. Schulz writes:

>> > It is my understanding that EFail would primarily affect the
>> cryptographic
>> > implementations of PGP within email clients. But mu relies on the GPG
>> > implementation of Emacs.

Efail relies on how a MUA handles / displays GPG output, i.e. the part
Mu4e is actually responsible for.

Efail relies on a client decrypting a maliciously composed message and
then sending the content of the decrypted message to a remote server.

The second part can be implemented in several ways, one of them is by
embedding an IMG tag with the message as part of the URL. Mu4e does not
load remote images, see mu4e-message.el:323 ff.

If the MUA does not load external components and does not execute
JavaScript in messages, there is simply no attach vector, period.

If messages with missing MDC are not displayed, there is also no attack
vector.

>> Right, but EFAIL does not happen while sending a message but it happens
>> while decrypting an encrypted message.

No, it happens while *displaying* the message because only then
back channels can be activated.


BTW, here is an interview with the Enigmail lead dev about Efail
(German, sorry). The tl; dr: the GPG-related problems were fixed months
ago but this was not acknowledged in the advisories.

https://www.heise.de/security/meldung/Enigmail-Chefentwickler-im-Interview-Efail-Veroeffentlichung-war-unueberlegt-4049783.html

[Christophe Troestler]

Hi,

On 16 May 2018 at 09:22 GMT, Arne Köhn wrote:
>
> If the MUA does not load external components and does not execute JavaScript in messages, there is simply no attach vector, period.

There is an area where mu4e could improve: when using mu4e-action-view-in-browser, we should by default disable embedded JS code and the loading of external images. Mu4e could add some JS and button to activate those on demand (to make an informed decision, it should be possible to see code/links of the disabled parts). We could even be more subtle by trying to detect links that contain tracking codes and have a separate button for them.

Best,
C.