Roundcubemail: EFAIL vulnerability

[nurupo]

It looks like a critical vulnerability related to decryption of PGP emails with S/MIME will be announced in 22 hours and 30 minutes [1], [2]. Since Roundcube does support PGP email decryption, it has Enigma PGP plugin, it might be wise to follow the vulnerability to see if any changes are required in Roundube's code.

[alecpl]

This is something about reading encrypted mail with HTML. From GnuPG devs side this does not sound as critical as in the announcement. Let's wait for more details.

[nurupo]

I assume you are referring to this. Yeah, let's wait for details before jumping to any conclusions.

[Timi7007]

They released the paper early. The full version is available and by the looks of it (see Table 5) Roundcube is affected. Also refer to efail.de

[alecpl]

Issues H7 and C3 described in Appendix D has been fixed in 1.3.5 and improved in https://github.com/roundcube/roundcubemail/commit/0716d499bc591f (not released yet). So, that's it.

Can we do more? One thing would be to not ignore GnuPG integrity protection warnings, but notify the user and stop message processing.

Something more? Did I miss something?

[Keisial]

GnuPG integrity protection warnings must not be ignored. Ignoring the warning and processing the message (combined with the other information leaks) is what leads to the use of the email client as a decryption oracle. Stopping the message processing is the right thing to do.

See upstream view on https://lists.gnupg.org/pipermail/gnupg-users/2018-May/060334.html

GnuPG also throws large warning messages if an MDC indicates a message
has been modified. In both cases, if your email client respects this
warning and does the right thing -- namely, not showing you the email --
then you are completely protected from the Efail attack, as it's just a
modern spin on something we started defending against almost twenty
years ago.

[github-johnny]

Unless I did something wrong, when I tested this on a test server with Roundcube 1.3.6 installed, it did not work. I don't think I did anything wrong in my process - this seems pretty clear.

On a side note: a WAF seems to protect against these types of shenanigans. Modsecurity was not impressed and had to be disabled for testing. Defense in depth FTW.

Nice work alecpl and team.

[alecpl]

Really I don't think these PGP/MIME attacks were possible even before Roundcube 1.3.5. It is because Roundcube parses every message part separately. It does not just merge all HTML parts. So, in the process all unclosed attributes/tags would be dropped or closed, but I didn't really test that scenario.

[Timi7007]

Regarding the soft failure, when the integrity check fails, the GnuPG Project seems to be considering switching to a hard/fatal error.

[alecpl]

From what I understand now, there's two cases

1. MDC protected message - if protection check fails the message is not decrypted (proper DECRYPTION_FAILED status).
2. No MDC in the message (true for very old messages) - GnuPG decrypts the message with only a warning.

So, what we need to do is to make the warning an exception and handle it as it was DECRYPTION_FAILED. Enigmail did exactly the same. However, their users started complaining immediately quite a lot about that. So, I guess we'd need to implement a way to display the message anyway, e.g. "The message does not contain modification detection code. Decrypting it might be insecure. [Decrypt]".

[alecpl]

Let's do it without the decrypt option/button for now. Fixed.