hoakley May 15, 2018 Macs, Technology

Do you use email encryption at all? macOS 10.13.4 update may help

Fuller details have now been published about the EFAIL vulnerabilities in PGP and S/MIME email encryption, at the authors’ dedicated website.

They claim that S/MIME encryption provided by Apple Mail, MailMate, Airmail, and Apple’s Mail on iOS, together with Microsoft Outlook and Thunderbird have been vulnerable, without any PGP installation. Additionally, the combinations of Apple Mail or Airmail with GPGTools, and Thunderbird with Enigmail, have also been vulnerable. Apple’s Mail, whether running on macOS or iOS, has also been vulnerable to direct exfiltration attack without user interaction.

If you use S/MIME or PGP encryption in any of those combinations, then you are most probably affected, and would be well advised to re-assess your risks.

As to mitigation strategies, the authors consider that “the best way to prevent EFAIL attacks is to only decrypt S/MIME or PGP emails in a separate application outside of your email client.” I don’t know how feasible that would be using, for example, Apple’s Mail app.

Regarding the strategy of disabling HTML rendering, they state “disabling the presentation of incoming HTML emails in your email client will close the most prominent way of attacking EFAIL”, but that does not solve all the problems. In the case of Apple’s Mail, it would appear to still leave encrypted messages vulnerable: “Apple Mail, iOS Mail and Mozilla Thunderbird had even more severe implementation flaws allowing direct exfiltration of the plaintext that is technically very easy to execute.”

Apple has been informed of these vulnerabilities on 15 Nov 2017 and 10 Feb 2018. It appears that macOS High Sierra 10.13.4 does address direct exfiltration of S/MIME email, with the following fix now reported in its security release notes:
Mail Available for: macOS High Sierra 10.13.3 Impact: An attacker in a privileged network position may be able to exfiltrate the contents of S/MIME-encrypted e-mail Description: An issue existed in the handling of S/MIME HTML e-mail. This issue was addressed by not loading remote resources on S/MIME encrypted messages by default if the message has an invalid or missing S/MIME signature. CVE-2018-4111: Damian Poddebniak of Münster University of Applied Sciences, Christian Dresen of Münster University of Applied Sciences, Jens Müller of Ruhr University Bochum, Fabian Ising of Münster University of Applied Sciences, Sebastian Schinzel of Münster University of Applied Sciences, Simon Friedberger of KU Leuven, Juraj Somorovsky of Ruhr University Bochum, Jörg Schwenk of Ruhr University Bochum Entry updated April 13, 2018

As of 0600 UTC on 15 May 2018, I cannot find any corresponding fix for iOS.

If you are affected by these vulnerabilities, then you will clearly need to make your own assessment of your risks and best mitigation strategy. However, it does appear that Apple has responded to the most severe bug in macOS Mail, and has at least mitigated the risk in using S/MIME in High Sierra’s Mail app. The situation with iOS Mail, and macOS apps which use PGP encryption seems less clear at present.

4Comments

Add yours

1

Michael Tsai - Blog - EFail Vulnerabilities in OpenPGP and S/MIME on May 15, 2018 at 7:20 pm

[…] Update (2018-05-15): Howard Oakley: […]

LikeLike
2

Sebastian on May 16, 2018 at 12:19 am

You’ve stressed already that this is a very complex issue, but it should be pointed out that this “fix” by Apple addresses one single aspect of Apple Mail’s part in it AT BEST. For one thing, unless I am completely misreading the text quoted above, Apple has only changed Mail’s behavior for the case of an “invalid or missing S/MIME signature”. But the attack is not at all dependent on any signature being invalid or missing; the authors even explicitly note that signing an encrypted email does nothing in the way of protecting the user. So I’m puzzled how Apple can think their fix fixes anything.

Also, the researchers detail (p. 20 of the published paper) four backchannels in Apple Mail (version 11.2), two of which work explicitly in the case of “valid/trusted S/MIME signed emails”, and another of which works independently of whether any form of encryption is used at all (via a simple plaintext header, so even in the absence of any HTML code!). Apple Mail is at version 11.3 now, but given the release notes quoted above it seems highly unlikely to me that those three loopholes have been closed. So anyone using S/MIME or PGP in Apple Mail should continue to consider himself vulnerable. (Hell, even anyone NOT using encryption but who has disabled remote content loading in Apple Mail should consider himself vulnerable, since Apple Mail nevertheless may poll a remote server!)

Generally, I am quite shocked by the amount of backchannels identified by the researchers in almost every current email app, Mac or otherwise. Frankly, I don’t expect this whole mess to be solved on the side of email clients, even though those are primarily responsible for it.

LikeLiked by 1 person
- 3
  
  hoakley on May 16, 2018 at 5:14 am
  
  Thank you. I agree. If I were to want to use encryption in Mail, I think I’d want to see a careful, and preferably independent, re-assessment of 11.3 against the multiple vulnerabilities which have now been revealed.
  Perhaps Bruce Schneier is right when he states that “reliably and easily encrypting e-mail is an insurmountably hard problem”. Unfortunately, he goes on to recommend using Signal or WhatsApp, both of which have also been blighted by vulnerabilities.
  Howard.
  
  LikeLike
  - 4
    
    Sebastian on May 16, 2018 at 11:46 am
    
    Right—it’s not that messaging apps have a significantly better track record than any other means of communicating securely. And while I have no illusions that perfect privacy could ever be achieved, that doesn’t mean we can’t face issues as they arise and continue to improve our implementations. Unfortunately, though, the reactions from the PGP community mostly seem to propagate the notions that “it’s all just the email clients”, or that all you have to do to be safe is disable HTML—both of which are misleading if not plain wrong, and in any case don’t seem to indicate proper concern with the issues at hand.
    
    In the short term, I believe much will depend on how the various mail client and plugin makers respond to this. From what I understand, nothing about the efail attacks requires fundamental reprogramming; but what is required is diligent closing of multiple loopholes, and—on the part of the plugins—maybe even some proactive measures against improperly behaving host applications. It may well turn out that some parties emerge from this as responsible and dependable actors while others do not. But as you said, there is enough warranted suspicion now that additional security studies should be carried out before email encryption is relied upon again, at least for any serious use case—an update with “We fixed it!” in the release notes will hardly suffice.
    
    LikeLiked by 1 person

·Comments are closed.

Share this:

Like this:

Related