EFAIL – Is PGP really dead?
A vulnerability affecting PGP and S/MIME has been recently published (https://efail.de/). These are two mechanisms used for email encryption. As a way to mitigate this vulnerability, it has been recommended to disable message decryption plugins installed in email clients, and above all, not using them to read encrypted messages.
But, wait… not reading encrypted messages? Wouldn’t it be more logical advising not to write encrypted messages? In this post we will try to understand what this vulnerability represents, why it happens and above all, what is the logic behind the problem being reading encrypted messages.
This vulnerability affects email encryption via two different mechanisms, although both of them rely on a similar concept. To understand the vulnerability, we will first see the easiest version of the vulnerability, although it is the one that is least applicable, as it requires an incorrect message processing by the email client.
PGP and S/MIME are very similar. They are based on an asymmetric cryptography mechanism, but the real encryption is performed symmetrically. As this vulnerability affects the symmetric part of the encryption mechanisms, we will treat PGP and S/MIME in the rest of the post as if they used symmetric encryption.
So, Alice wants to send a password to Bob. As she knows that Eve is interested in obtaining this password, and that Eve can intercept the message on-transit, she is sending it within an encrypted message. She encrypts the message and sends it to Bob, who is able to decrypt it successfully. Eve intercepts the message but, as it is encrypted with a (for her) unknown key, is unable to decrypt it and obtain the password.
But Eve knows that Bob uses an email client that is vulnerable to the simple version of this vulnerability, so she sends a specially crafted HTML email to Bob. This email consists of three sections (it is a multipart message). The first and last sections are in the clear, and generated by Eve, so she can control their content. As second section she sends the original message as sent by Alice (which she had managed to intercept but not decrypt). As soon as the message arrives, Bob opens it. His email client detects the three sections and that the second one is encrypted. So, the client decrypts it and shows the content to Bob.
And, what is the content? Eve has crafted the message so that the first section contains a <img> tag, indicating that the client should download an image specified in the URL included in that section. Still, we can see that the “src” attribute is not terminated, as it is lacking the terminating quotes. The termination of this attribute and the end of the <img> tag is included in the third section, also crafted by Eve. This way, Eve has managed to enclose the second section (the content sent by Alice) within the URL of the image. As Eve controls the first part of the message, she can indicate that the image should be downloaded from a server controlled by her. The content of the decrypted message will be included in the URL and Eve only has to check the URL Bob requests to obtain Alice’s message decrypted.
So, this is the reason why the danger lies in reading encrypted emails. Reading a malicious email may result in the email client accessing an external resource, silently sending to Eve in the clear the content of any other encrypted message. For instance, Eve could have prepared her malicious message so that the image is loaded in a hidden iframe, so as not to arise any suspicions.
In this case, the vulnerability happens because the email client takes three independent sections of the message and merges them, generating a single HTML tag. A correct email client should show the three sections separately, so that it is impossible to create an <img> tag containing Alice’s original message.
This is the “easy” version of the vulnerability. But, assuming that we have an email client that is not vulnerable, but shows the three sections in an independent way… is it still possible to exploit this vulnerability?
To better understand this version of the vulnerability, one has to understand that PGP and S/MIME use block ciphers. This implies that the original message is divided in fixed-size blocks. Each input block is then processed and results in an encrypted output block of the same size. Related with this mechanism, the symmetric encryption used by PGP and S/MIME present two problems.
First, they use “malleable” algorithms (technically, encryption modes). This means that it is possible to reorder or repeat blocks of the message and, apart from certain blocks that will be decrypted as garbage, the rest of them will be decrypted correctly.
On the other hand, if an attacker knows the original (unencrypted) content of two consecutive blocks, he can craft pairs of blocks containing garbage in one of the blocks, but the text he desires in the other block. As most PGP and S/MIME messages start with a series of fixed headers, the attacker is able to identify the unencrypted content of the first blocks, and thus he is able to craft these kind of blocks, injecting the text he desires in the text that will be decrypted by the unsuspecting user.
With knowledge of these two problems, Eve i sable to derive a malicious message from Alice’s original message (even without knowing the cypher key). After decryption this message will contain:
- Garbage sections
- Sections with content controlled by Eve
- Sections with the unencrypted message created by Alice
And after having seen the first version of this vulnerability, it is easy to know which kind of message she will craft…
Where the sections “XXXX” indicate parts of the message Eve has no control over, and that neither come from Alice’s original message. In the real world the decrypted message has additional constraints and does not have this exact appearance. The parts Eve controls (and the garbage ones) have a fixed size (the encryption block size), which makes Eve’s attack more difficult. Still, the previous message illustrates the concept behind the attack.
This version of the vulnerability affects any email client that decrypts PGP or S/MIME messages, and that downloads external information associated to them (in this case, the malicious “image”). The vulnerability is due to the encryption modes used by PGP and S/MIME being malleable, as we have seen, as they are protocols that were defined many years ago. Nowadays, new encryption modes have been defined that provide a characteristic known as AEAD (Authenticated Encryption with Associated Data), such as GCM. These modes are able to automatically detect modifications to the message, preventing Eve from crafting a malicious message without knowledge of the symmetric encryption key. Bob’s email client would automatically detect that the message has been tampered and would never show it. In reality, PGP has a certain degree of protection against these modifications due to a mechanism known as SEIP, but in the EFAIL article it is shown that it can be circumvented by performing a “SEIP downgrade”.
Summarizing, even though there has been a lot of worries about this vulnerability, it would be unfair to say that PGP has been compromised (in fact, there are many discussions over this being a real PGP vulnerability or an email client one). PGP has its problems (such as malleability of its messages and the possibility to downgrade SEIP protection) but up to certain point it is still perfectly valid. The problem, in this case, is the possibility to “exfiltrate” the original content of encrypted messages using functionalities included in most of email clients.
Due to this it is recommended to disable PGP and S/MIME plugins in email clients, to prevent that decryption of a malicious message provides an attacker with information about the original content of a legitimate encrypted message. Still, knowing these limitations and knowing the outreach of this vulnerability, it is possible to use these encryption mechanisms, taking care to use external tools for decryption (so that HTML content is not downloaded), and looking for garbage data in the content, which could point to crafted messages.
Disabling HTML parsing in received messages can also make an attacker’s life more difficult, but exfiltration using <img> tags is not the only way an attacker can extract information, so this operation does not provide 100% security.