[Gpg4win-devel] efail statement draft v7

[Andre Heinecke]

Hi,

On Thursday, May 17, 2018 9:46:44 AM CEST Bernhard Reiter wrote:
> Attached a draft that Andre, Werner and myself have drafted
> since Monday to be an official statement for Gpg4win.
> It is my version, may still contain errors.

Already looks very good to me. I had some minor corrections.
Attached you can find an updated version and a diff of the changes I made.

I've changed the contents in the crypto gadget / smime part for files. As I 
thought more about it I've also, realised that the crypto gadget attack does 
not change much for files.
It changes a bit e.g. if one imagines an HTML file.
But for something else like an office macro or executable, these always needed 
to be from a trusted source. Verified by a signature. I tried to say that more 
clearly as direct advice.

I'm not yet sure how we are going to improve S/MIME for files. E.g. a better 
warning, a File Dialog that queries for a signature file etc.
So I would leave concrete steps out of the statement for now.

Best Regards,
Andre

-- 
Andre Heinecke |  ++49-541-335083-262  | http://www.intevation.de/
Intevation GmbH, Neuer Graben 17, 49074 Osnabrück | AG Osnabrück, HR B 18998
Geschäftsführer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: efail-gpg4win-statement-20180517ber7ah1.diff
Type: text/x-patch
Size: 4522 bytes
Desc: not available
URL: <http://lists.wald.intevation.org/pipermail/gpg4win-devel/attachments/20180517/82e868f3/attachment-0001.diff>
-------------- next part --------------
**Draft v7 BER**
= Gpg4win Statement on Efail Research

== Summary

On the 14th of May 2018, a group of researchers published
a number of problems in mail applications on [[https://efail.de/|efail.de]].
Most mail clients supporting
S/MIME are affected as well as a few clients supporting OpenPGP.

They have tested OpenPGP support with GpgOL (our Outlook-Addin)
and it behaved well for supported versions of Outlook.

The bottom line is, that you can keep using Gpg4win while:
* You pay extra attention to the ability of your S/MIME recipients to handle
  crypto emails well, until the majority of other email clients has been
  updated.
* You never load external references in encrypted HTML emails, especially
  for S/MIME. Make sure that the default is still //off//.

The Gpg4win Initiative plans to release another minor
version soon that takes further precautions, removes Outlook 2007 support,
and improves some edge cases for its S/MIME support.


== Details

On the 14th of May 2018, a group of academic researchers from Germany
and Belgium published a paper called
[[https://efail.de/efail-attack-paper.pdf|Efail: Breaking S/MIME and OpenPGP Email Encryption using Exfiltration Channels (draft 0.9.0)]] on their website.
They show of number of problems with how email encryption is currently
implemented. A few mail clients supporting OpenPGP and most clients
supporting S/MIME are affected.


=== "Direct exfiltration" in other clients

Two major email clients, Apple Mail and Thunderbird/Eigmail, have been found
to be vulnerable to an attack called "direct exfiltration".
**Gpg4win's Outlook-Plugin** and for example the
Free Software ("Open Source") mailers Claws, Evolution, KMail, K9-Mail,
Mailvelope, Mailpile and Mutt were **found to be immune.**

The attack is made possible if the email client concatenates
different mail parts and interprets them together as HTML with external
references. This can be used by an attacker: A manipulated encrypted email
tricks the email client into sending decrypted plaintext
to a webserver of choice, when fetching the references.

As this attack works on the sender and all recipients of an encrypted email,
all the used email clients have to be safe for your communication to be safe.

**Advise: Make sure to only send encrypted emails to people that
are using clients in a safe way. Put special attention to the vulnerable
clients listed in the bottom of efail.de until fixed versions are widely
available.**
Check updates from a computer emergency response team that feels
responsible for you, e.g.
[[https://cert-bund.de/advisoryshort/CB-K18-0673|CB-K18-0673 (Germany)]]
and their [[https://www.bsi.bund.de/EN/Service/Information/article/efail_vulnerabilities_14052018.html|"Efail" vulnerabilities - What you should know now]]
or [[https://www.kb.cert.org/vuls/id/122919|VU#122919 (USA)]].

Note:
* Each communication partner already had the responsibility
  to keep contents coming from you confidential on an organisational and
  technical level. Right now some may just not be informed about the version
  of their product being vulnerable to this specific attack.


=== "crypto gadget" attack

If an email is only encrypted and not signed, an attacker can
reorder, delete or insert data, which will be partly decrypted.
The current OpenPGP protocol as it is widely used for about 15 years
includes protection against this manipulation.
Current S/MIME specifications also allow for protection, but this has not
been deployed in practice.
The manipulation can cause an insecure mail client to
leak decrypted data to a remote attacker through a backchannel like an
external reference. The attack does not work, if there is no usable
backchannel.


==== OpenPGP

The GnuPG crypto-backend in Gpg4win detects such manipulations
and issues an error to mail clients, unless the sender or receiver
deliberately uses weak settings.
Most mail clients using Gpg4win respect the errors issued by GnuPG.
Especially Ggp4win's Outlook Add-in "GpgOL" will not display
any data in this case which makes it
**immune against the OpenPGP crypto gadget attack.**

The combination of GpgOL and Outlook 2010 or newer
in addition does not load external links by default.
Automatically loading links in mails is a privacy problem in
itself and has long been discouraged for security reasons.
Only some mail clients load external URLs by default.

An exception to this is GpgOL for Outlook 2007. Since
Version 3.0 Gpg4win already shows a warning that this part of GpgOL
is unmaintained. Users should stop using Outlook 2007 as it does not receive
updates its vendor anymore. Support for this version
will be removed in the next Gpg4win revision.


==== S/MIME

Deployed standard S/MIME implementations do not have a way to detect the
mentioned manipulations when using unsigned mails.
This is described in the current S/MIME standard (STD-70 aka RFC5751).

The problem arises if clients still show contents in case of a missing or
bad signature for an encrypted mail and they are loading external references
to open a backchannel.

Note that there is an S/MIME mode to GpgOL, which is disabled by default
and has not been tested by the researchers. They tested the S/MIME
mode of KMail which is also using GnuPG as an S/MIME backend
and only found that a user can manually trigger a backchannel.

As a precaution against any S/MIME message modification attacks
in Outlook the Gpg4win team **recommends to not load external
references, e.g. images, in mails and refrain from using HTML-mails.**

Automatic download of images could have been enabled in Outlooks options
under: "Trust Center->Automatic Download"
The automatic download is disabled by default, thus
**GpgOL is immune against the S/MIME crypto gadget attack**.

A rarely used feature of Gpg4win is to apply S/MIME crypto operations
to files. When executing files users should always **ensure
that it comes from a trustworthy source** by checking a signature.

Note: When receiving an email or file without a cryptographic signature you
  already had to be careful that the contents could have been manipulated and
  thus you should not use unsigned active contents, like executables,
  office macros and other scripts.


== Media coverage of the larger picture

While the researchers have chosen an imported topic to work on and their
tests demonstrated important weaknesses in implementations
and the need to update related standards, there is some concern in the
Gpg4win team about how the findings got reported in some media.

The broken email clients allowing "direct extraction" are worrisome
and may need broad media coverage to use reach their users, it would
have been better to wait with reporting until better fixes and instructions
were available. It is a classic situation that is happening several times
during the year that some implementations are found to be defect and updates
are needed. It happens to many applications and does not indicate
a more general problem.

The problem with S/MIME implementations missing integrity protection
is serious and we hope that vendors will quickly agree on implementing
RFC6476 or something similar. This seems to be the most interesting
finding, as it cannot be resolved quickly and it reminds everybody
to be careful with contents that can become active as a backchannel
or exploit code.

The situation with OpenPGP is different:
When used sensibly, the current OpenPGP specification, most implementations,
and GnuPG itself continue to provide very reasonable protection.
The integrity detection MDC is
used for more than 15 years and GnuPG itself issues a clear indication
for a manipulated email and even a hard failure since 2015.

On a general note: OpenPGP and S/MIME are protocols which are
openly documented with several implementations and variants.
OpenPGP is additionally designed to have a de-centralised trust structure.
They need to consider backwards compatibility more than a single vendor,
but they are also less vulnerable against a serious implementation
defect in one product.

When considering other solutions for communicating in private our
recommendation would be to also check if it is Free Software ("Open Source"),
openly documented, de-centralised and has an understandable business model
where users are the customers.

Security is a complicated matter and thus profits from calm reporting.
A pressure to simplify and report quickly on the research findings may
have caused more confusion than necessary. It is for us as readers to
honor a thorough style of journalism that may need more time to shine.


2018-05-16
Bernhard Reiter
Andre Heinecke
Werner Koch

CC-BY-SA 4.0
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.wald.intevation.org/pipermail/gpg4win-devel/attachments/20180517/82e868f3/attachment-0001.asc>