The Call of the Open Sidewalk

From a place slightly to the side of the more popular path

User Tools

Site Tools


pgpfan:efail

This is an old revision of the document!


The EFAIL Hoax

In 2018 a security issue dubbed EFAIL1) was all over the technical media and even leaked into the regular media. Many of those articles were misleading or incorrect. Some gave dangerous advice. Here is an example of a particularly hyperbolic headline:

The word “Hoax” in the title of this article refers to the attempts to make it seem that EFAIL represented some deficiency in PGP. That was simply not true.

EFAIL was a list of different ways to cause inherently insecure message content (HTML email) to leak decrypted messages. Such data leakage was a known issue and was under routine exploitation at the time. This fact alone should be enough to convince most people EFAIL had nothing to do with either PGP (or S/MIME). When you have a hole big enough to drive a truck through there is no extra value in discussing the size and shape of the truck. Unfortunately in the case of EFAIL we need to spend time discussing truck dimensions.

The EFAIL effect is triggered by creating a message so that when it is decrypted and then interpreted as HTML the interpretation process will leak the decrypted message. Something like <img src=“efail.de/ placed immediately before the desired text would create a URL that would leak the message to a web server controlled by the attacker. The details depend on the mail client and there are probably a lot of different methods available, limited only by the attacker's cleverness and imagination. The EFAIL paper listed several.

One of these methods (dubbed “CFB gadgets”) involved modifying the encrypted HTML message so that when it was decrypted and interpreted it would leak the message by the EFAIL effect. The suggestion was made that the OpenPGP specification was flawed for allowing such attacks in the form of a CVE2).

The traditional solution to this particular modification is an extra check on top of the encryption called authenticated encryption. The suggested fix in the EFAIL paper was the addition of authenticated encryption to the OpenPGP specification. There is a fundamental problem with this line of thinking.

The OpenPGP specification already has a simple integrity check called the MDC that is entirely adequate to detect this particular attack. The addition of authenticated encryption to PGP would make no difference at all for any of the demonstrated EFAIL leaks. It is not possible to suggest authenticated encryption here without also acknowledging that the OpenPGP specification is not susceptible to EFAIL. It was on that basis that the CVE was disputed.

This might be a good place to point out how wildly impractical the CFB gadget method is compared to the other methods listed in the EFAIL paper. To make a CFB gadget attack work you need to know the first 11 bytes/characters of the unencrypted message. The EFAIL paper suggested that the use of the multipart/mixed MIME attribute could allow as many as 500 guesses at those 11 bytes/characters in the same message. Unfortunately the paper did not give any examples of clients where this might work. The three clients I tested3) would not even recognize a second HTML section in a message, much less decrypt and interpret it. This is important because EFAIL is the sort of attack you only get to do once. The attack email is seen by the user and would normally inform them of the fact they were under some sort of attack.

The spin required to make this a PGP problem was unfortunate in that it distracted from the actual issue of inherently insecure message content in encrypted messaging. The good work done by the security researchers ended up being in a sense wasted. Inherently insecure message content is still a serious issue today (2020).

A more fundamental problem with all this is that when used for messaging, PGP uses a combined identity/integrity check called a signature. In PGP messaging both the MDC and hypothetical authenticated encryption are irrelevant. So this ends up being a kind of a straw man. This would of been much better if it was discussed in terms of how PGP actually works and how these vulnerabilities affect the clients in that context.

The OpenPGP standard and implementations of that standard suffer from genuine security weaknesses from time to time. That is why the media blowup over EFAIL is so odd.

PGP FAN index

pgpfan/efail.1599854707.txt.gz · Last modified: 2020/09/11 20:05 by b.walzer