The e-Fail authors provide interesting experimental data on how easy it is to exploit e-Fail (e.g. by crafting password reset e-mails) and how many e-mail clients are susceptible to the attacks. Essentially, most of the most popular e-mail clients are vulnerable to some degree but carrying out the attacks in practice may be difficult. The authors suggest that they expect that, in 40% of cases, an e- mail plaintext may be leaked using a single attack attempt, but many e-mail clients require either a man-in-the-middle or user interaction in order to carry out the exploit. 23 out of the tested 35 e-mail clients were exploitable; 3 were vulnerable to the simple image-based attack described above.
The OpenPGP standard does provide an integrity checking method (Message Modification Codes) which permit e-mail clients to detect and drop e-mails that have been maliciously modified; if available in your e-mail clients, this option should be enabled at both sender and receiver. Unfortunately, the S/MIME standard does not currently include such provisions.
The short term mitigation advice, until patches can be issued, is to avoid decrypting S/MIME or PGP emails within e-mail clients; instead, e-mails should be decrypted in a separate application which cannot open the back-door to leak the plaintext. One way to do this is simply to temporarily delete the PGP decryption keys from your e-mail client (but retain them in a backup so that they can be restored once the e-Fail vulnerability is patched).
If this is not feasible, HTML rendering of incoming emails should be disabled with e-mail clients, which should prevent the leakage channels discussed in the e-Fail paper being established; however, there may be other methods to exploit these vulnerabilities outside of HTML (e.g. checking certificate validity) which will not be mitigated by disabling HTML rendering.
Alternatively, outgoing network requests from e-mail clients could be temporarily disabled e.g. via firewall configuration (although this will affect rendering of innocent e-mails as well).
The full impact and implication of e-Fail will, no doubt, become clearer in the coming days as more details and mitigation patches are released. As always, we recommend monitoring the situation and applying authorised patches as soon as practically possible. It does appear that the initial rumours and reports were somewhat dramatic and the practical impact may be less due to the difficulty of actively exploiting e-Fail with specific e-mail clients.
Since e-Fail relies on observing protected e-mails, it may be prudent to evaluate the security of your e-mail and end-point infrastructure – as mentioned, the most likely methods to obtain such e-mails are to act as a man-in-the-middle to intercept traffic between clients and e-mail servers, or to compromise either a user device or the e-mail servers. Thus, ensuring that e-mail traffic uses an authenticated and confidential channel, and hardening both devices and servers, may help mitigation. One important aspect to keep in mind however is that, as an e-mail sender, the security of your outgoing messages relies on the security of all recipients – if any one recipient has not mitigated this vulnerability then the e-mail could be leaked.
The possibility to modify e-mail messages also has wider implications than exploiting e-Fail; for instance, it may be possible for attackers to maliciously modify attachments unless additional authentication mechanisms are applied.
For more detailed information, see the e-Fail website which also contains the paper with the full details.