By now, everyone and their dog will have probably heard about the so-called “Efail” attack, and read the researchers’ description that was released early (because although they had managed to create a logo and buy a domain name, they didn’t manage to get an embargo to stick.)
Some folks may even have read the researchers’ technical paper detailing Efail.
Here’s the issue summarised by the researchers themselves:
In a nutshell, EFAIL abuses active content of HTML emails, for example externally loaded images or styles, to exfiltrate plaintext through requested URLs.
The attacker changes an encrypted email in a particular way and sends this changed encrypted email to the victim. The victim’s email client decrypts the email and loads any external content, thus exfiltrating the plaintext to the attacker.
Sneaky. However, in order to do this an attacker needs to have access to past encrypted emails you have received, as the researchers acknowledge:
To create these exfiltration channels, the attacker first needs access to the encrypted emails, for example, by eavesdropping on network traffic, compromising email accounts, email servers, backup systems or client computers. The emails could even have been collected years ago.
That makes me raise an eyebrow about just how much of a realistic risk is posed by the Efail attack. If a malicious hacker already has access to your email servers, networks, and such like, there’s probably all manner of worse and less convoluted things they could be doing to make your life a misery, steal secrets, and destroy your privacy.
Here are some of my other thoughts:
- Yes, it’s a sneaky attack method. But it’s not reliant on any inherent weakness in the PGP/GPG encryption being used. Instead it exploits users who haven’t told their email clients to stop remote or external content from being automatically rendered.
- It’s not strictly a brand new problem either. The root problem of mail clients attempting to display corrupted S/MIME messages has been known about since 2000 or 2001. A better-behaving email client might notice that, to use the researchers’ example pictured above, the HTML image tag does not get closed properly until after the encrypted parts of the email message.
- Who would be interested in going to all this effort to read your messages? Intelligence agencies and state-sponsored hackers are the most likely culprits. And yet, because the attack relies upon past encrypted emails being sent to the target, this is a very visible and obvious attack method. Typically state-sponsored spies don’t want their victims to know that they are being targeted.
- Is this kind of attack hard to spot? No. It wouldn’t be tricky I suspect to write a script that scanned incoming email for malformed IMG tags, for instance.
- Is Efail a good reason for folks who use PGP/GPG to disable it entirely? I don’t think so. You’re probably putting yourself at greater risk if you have something sensitive to communicate by reverting to unencrypted email. Of course, there are other end-to-end encrypted messaging solutions out there which don’t face the same clunky challenges as encrypted email.
In summary:
The sky is not falling, stop freaking out.
Keep your email clients updated with the latest security patches as they become available.
Consider disabling rendering of remote content until the issue is resolved (this will have all manner of other privacy advantages), and maybe even embrace good old fashioned non-HTML email!
You may also wish to prevent automatic decryption of email messages, and require users to manually request decryption instead to reduce the chances of data leakage via active content.
Hello,
Thanks for this – good read. Love the podcast too. Me not being a hard-core security guru, I was hoping for more info on this:
"Of course, there are other end-to-end encrypted messaging solutions out there which don’t face the same clunky challenges as encrypted email."
Signal is perhaps the most commonly cited example of a secure messaging app.
Graham, well done for countering the FUD on this.
These questions come to mind:
1. Can the EFAIL vulnerability be exploited if the HTML content of an encrypted message is limited to formatting attributes and does not make a call to any external sources?
2. What about active links that simply pass a URL to the recipient’s browser, but don’t require the message body to receive content from any external source?
If I correctly understand the way this attack is implemented, the EFAIL vulnerability can be exploited when a message with encrypted HTML content makes a call to an external source in order to load the external content into the message body, such as an image file stored on an external server…right?
But not all content with HTML attributes makes calls to external sources.
For example, the principal (and most compelling, from my perspective) reason I use HTML messaging is that it includes some very useful forms of content formatting, such as font variations (bold, italics, underline, and font size), hierarchical formatting (indentation, bullet point or ordered lists), and tables.
None of those features require a call to external content in any full-featured email client (Thunderbird, SeaMonkey, Outlook…etc.) Also, I can include active links to web pages—as references, not for importing content into the message body.
Those formatting options are excluded from “good old fashioned non-HTML email”.
I have occasionally heard (not from Graham, I hasten to stipulate) the assertion that “if you can’t say it in plain text, it doesn’t need to be said”. That's a narrow view of the functionality and potential utility of electronic messaging. The truth is that message formatting (when used properly) is an important part of the information content of a message.
Maybe I'm missing something, but I don’t see how EFAIL can be a problem if an encrypted message’s content is limited to HTML formatting attributes that are built into the recipient’s mail client.
Your logic seems sound to me.
If only basic HTML is used to make the email look pretty rather than loading external content, then the Efail attack doesn't work.
Hi Gram,
I'm going to start selling Hammers of varying sizes & weights! Also, small microwaves just for the Tinfoilhat crowd who need to nuke their chips ????
Disabling HTML (including not just "active" HTML but also remote fetching of images) should be sufficient to mitigate the vulnerability in a given mail client. Unfortunately, you'll also need to make sure the vulnerability is mitigated in the clients of all the people you exchange PGP encrypted email with :(