Differences

This shows you the differences between two versions of the page.

--- pgpfan:efail [2020/06/22 16:22] – [EFAIL Was Not Really an Email Client Issue] typo, add index b.walzer
+++ pgpfan:efail [2022/05/16 21:17] (current) – Typo b.walzer
@@ Line 1: / Line 1: @@
 ======The EFAIL Hoax======
-In 2018 a security issue called [[https://efail.de/|EFAIL]] 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:
+In 2018 a security issue dubbed EFAIL((https://www.usenix.org/system/files/conference/usenixsecurity18/sec18-poddebniak.pdf)) 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:
   * [[https://www.wired.co.uk/article/efail-pgp-vulnerability-outlook-thunderbird-smime|We're calling it: PGP is dead]]
-EFAIL was a clever use of image URLs in HTML emails to leak decrypted messages. Such data leakage was a known issue and was under routine exploitation. This particular use was probably not very much of a surprise.
+To be completely clear... The word "Hoax" in the title of this article refers exclusively to the media attempts to make it seem that EFAIL represented some deficiency in PGP. It also can be considered a satire of needlessly provocative headlines. EFAIL represents real issues. They were just misrepresented.
-The EFAIL thing still comes up in discussions about PGP so I pretty much have to address it in this series of articles.
+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.
-=====EFAIL Was Not a PGP Issue=====
+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.
-My main argument does not involve many of the actual details so I will use a  physical analogy:
+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 CVE(([[https://nvd.nist.gov/vuln/detail/CVE-2017-17688|CVE-2017-17688]])).
-Your business owns a building. That building has a hole in the wall. The hole isn't really a problem so you don't pay much attention to it. Occasionally the odd tool goes missing. You suspect the tools are going out through the hole but concentrate on more serious issues.
+The traditional solution to this particular modification is an extra check on top of the encryption called [[pgpfan:authenticated|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.
-Then one day you come in and both of your trucks are missing (the keys are kept on a rack on the wall). It is quite the mystery until someone notices that the hole is of a size and shape that would allow a truck to pass through. The trucks must be deficient in some way:
+The OpenPGP specification already has a simple integrity check called the [[pgpfan:mdc|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. The CVE was most likely disputed on this basis.
-  * The trucks were too small. A larger truck would not of fit though the hole. The new trucks should be larger or should have extensions welded to the frame.
+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. Even if there were email clients out there that will allow hundreds of attempts at decoding anonymous encrypted messages in the same message while ignoring hundreds of modification errors the attack was still quite impractical. The attack email is seen by the user and would normally inform them of the fact they were under some sort of attack. Then they would likely have reported it and the email client(s) would have fixed their bug(s). This sort of thing is typical for encrypted email where the recipient always gets to see the attack message.
-  * The trucks should of refused to start after business hours.
-  * The trucks were too complex and confusing in their operation. It was not obvious that leaving the keys on the wall could be a security issue. The keys should be left in the ignition to get them out of sight.
-Somewhat obviously, the point here is that when you have a hole big enough to drive a truck through, it is pointless to blame the truck. That is particularly true in this case where the two trucks represent entirely different encryption systems (PGP and S/MIME). The hole represents data leakage using URLs in HTML emails. The tool pilferage represents the ongoing exploitation of such leakage for unauthorized tracking of email recipients.
+It is sometimes claimed that OpenPGP implementations (GnuPG in particular) are at fault for EFAIL because they "release unauthenticated plaintext". After all, if the OpenPGP implementation had detected that there was a potential modification and had blown up with an error before releasing any of that modified text, then none of this would of happened.
-The EFAIL disclosure resulted in no functional changes to the OpenPGP standard or implementations of that standard. There was simply nothing to be done as the system was being used entirely as intended and produced results entirely as expected. That would still be true even if the researchers were able to defeat the OpenPGP MDC integrity check. The word "Hoax" in the title of this article refers to the attempts to imply that EFAIL represented some deficiency in PGP.
+//Any// data leak could be prevented by detecting the potential problem ahead of time and then refusing to release data. We are adding a known insecure mode (HTML email) to a system and then blaming the cryptography code for not anticipating the potential problem when things inevitably go wrong? This seems a bit random. At any rate, the "just blow up" approach is not practical for the sort of offline applications that OpenPGP is normally used for. An email shows up with a possible modification. Then what? You can't just show the user a blank screen. It would be a perfectly reasonable approach to warn the user and then show the message in a very safe environment. If the user is under attack they need to be allowed to try to figure out how. Chances are it will just be some sort of transmission error. The same sort of thing applies to encrypted files. The user might want to try to recover the corrupted data.
-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.
+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).
-To be clear (and fair) the EFAIL disclosure does not represent any sort of real deficiency in S/MIME either.
+A more fundamental problem with all this is that when used for messaging, PGP uses a combined identity/integrity check in the form of a cryptgraphic signature. In PGP messaging both the MDC and hypothetical authenticated encryption are less important compared to the question of allowing the handling of anonymous (invalid or missing signature) messages in a very insecure way. 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.
-=====EFAIL Was Not Really an Email Client Issue=====
+The OpenPGP standard and implementations of that standard have suffered from security weaknesses of greater significance than EFAIL with no media coverage at all. That is why the media blowup over EFAIL is so odd. I have no idea why this ended up so wrong. What ever the reasons, this serves as yet another indication of the poor quality of the technical press.
-EFAIL is really just an extreme example of the [[pgpfan:html_email:HTML email]] problem. EFAIL only can work when the email client allows loading of remote assets though things like image URLs. In that configuration the email client has no way to distinguish between legitimate URLs and those that contain data to be leaked. The problem is simply not solvable at the email client level as stated for the EFAIL case.
-There was some unhappiness about how some email clients dealt with bad PGP MDC integrity checks. Some improvements were made. This all ended up being a distraction from the more [[pgpfan:email_clients|fundamental issues]].
 [[pgpfan:index|PGP FAN index]]