GPGMail and efail: Everythings safe?
https://www.macrumors.com/2018/05/14/vulnerabilities-in-pgpgpg-emai...
Best wishes ... Joern
Comments are currently closed for this discussion. You can start a new one.
Keyboard shortcuts
Generic
| ? | Show this help |
|---|---|
| ESC | Blurs the current field |
Comment Form
| r | Focus the comment reply box |
|---|---|
| ^ + ↩ | Submit the comment |
You can use Command ⌘ instead of Control ^ on Mac
Support Staff 1 Posted by Steve on 14 May, 2018 11:35 AM
Hi Joern,
GPG Suite 2018.2 which mitigates against this attack is coming very soon.
As a temporary workaround against efail
Kind regards,
steve
2 Posted by Lorena on 16 May, 2018 08:22 AM
According to the Q&A of the attack, that might not be enough to be safe :)
https://efail.de/#i-have
3 Posted by Nichol on 16 May, 2018 11:01 AM
Isn't this problem only with email that is not 100% encrypted, but contains an encrypted part inside an unencrypted part. So that type of mixed emails should always be treated with extra caution. A warning. And making sure that the encrypted bits get insulated from the unencrypted bit that may contain the bad bits of html. And something else?
Am I right to think that a 100% pure encrypted email cannot be the victim of EFAIL. But a main problem is that you cannot easily see what is in these invisibl
What are the plans for the coming upgrade?
4 Posted by Paul on 22 May, 2018 02:26 PM
In https://www.golem.de/news/pgp-smime-thunderbird-update-notwendig-um... (in German), Hanno Böck discribes a problem of Enigmail that might also apply to GPGTools when remote content is disabled. He uses an HTML form with an invisible button covering the entire e-mail. A click anywhere in the mail window submits the form and leaks the decrypted plaintext.
I did not find any comments on that on the official twitter account. Do you have an eye on that? Or is there reason to believe that this attack would not work in Apple Mail?
5 Posted by Nichol on 22 May, 2018 07:06 PM
It looks like the problem is with html in email first, and the treatment of multipart mails second. When combined with anything that is encrypted. The problem wasn't really with including images, although the <img tag was the first to use the efail trick.
Emails with just one single encrypted message, and nothing else should be safe. As they con't have any parts to put html in, that can run across the encrypted message.
Email readers that force some strong compartmentalisation of the parts could be safe. But that doesn't seem to be the way this mime thing has been set up.
I guess it makes sense within the current weak environment to have rather strong rules to only send encrypted messages without html, and only in one single part. As it is not easy to even see if there is html or not. And then the email reader is the only thing that can actually estimate if the email is of the (usual) type that is safe.
6 Posted by Paul on 22 May, 2018 07:20 PM
If I understand correctly, it is currently not safe to open an untrusted email with Apple Mail + GPGTools, even if loading remote content is disabled, right?
Shouldn’t that be reflected in the pinned tweet? Frankly, it would make EFF’s recommendation of temporarily uninstalling sound much more reasonable.
7 Posted by Craig Hicks on 23 May, 2018 03:16 AM
At some finite date in the (hopefully) near future, most email client over GnuPG users will have an EFAIL-reading safe system setup, if they don't already. MDC will be strictly enforced.
However, the situation for a secret message sending is not so good. There is no way to guarantee that the reader/receiver has updated their software and/or settings. Statistically speaking security updates are not enforced uniformly; there are always laggards. Therefore, without adequate additional precautions, there will always exist the possibility of a secret message writer/sender's message being read by an EFAIL attacker.
A solution to this problem is proposed in
"A Solution for Sending Messages Safely from EFAIL-safe Senders to EFAIL-unsafe Receivers"
https://github.com/craigphicks/efail-safe-send-to-insec-recv/wiki
Because each block is vulnerable, the solution works by individually protecting each block against being wholly included as part of an HTML attribute. It is possible because the attacker is restricted to dividing the message along encrypted block boundaries.
The solution is very simple. The plaintext to be encrypted in a single block is divided into two parts. This first part is obfuscating string o, and the second part is message m. The choice of o prevents m from being included in the attackers attribute value.
Specifically, the obfuscating string o must have a least the three characters single quote ('), double quote ("), and space ( ). That's enough for force the closure of the HTML attribute and protect the message m.
You can play around with the attackers choice of starting delimiters in this Try jsoup sandbox example
https://try.jsoup.org/%7E_nyXks5PuAs-zJeek8CVhpuAvtI
When decrypted by the user in its raw form the total message will be human readable but a little ugly because it contains the obfuscation string o, but it will be safe from EFAIL.
More detail is included in the above github document.
Because alignment of the obfuscation part with the encryption block boundary is critical, the implementation should be done in the base module, e.g. GnuPG, rather than an email client. Of course it is not a GnuPG fault, it just happens that's the obvious safe place for this proposed solution.
8 Posted by Hector Cabrera on 30 May, 2018 08:55 PM
Hi Joern and Steve, any updates about this? when can we download the new version with fixes?
Support Staff 9 Posted by Steve on 23 Jun, 2018 10:55 AM
GPG Suite 2018.2 included efail fixes for macOS High Sierra.
GPG Suite 2018.3 backported the fixes to macOS Sierra.
The latest version is available on https://gpgtools.org/ and we highly recommend updating to 2018.3.
10 Posted by Jörn Pönitz (.c... on 23 Jun, 2018 01:13 PM
Thank you for noticing me …
Already installed!
Best wishes, Joern
Luke Le closed this discussion on 25 Jun, 2018 07:44 PM.