[Gpg4win-devel] efail -> improvements

Andre Heinecke aheinecke at intevation.de
Tue May 15 10:07:58 CEST 2018


Hi,

On Tuesday, May 15, 2018 8:47:38 AM CEST Bernhard Reiter wrote:
> On an email just send to gnupg-devel@
> I'm suggesting to change GnuPG and frontends
> to not show any contents, unless there is integrity protection by either
> 
> >  a) MDC
> >  b) AEAD
> >  c) a signature over the whole contents from someone where it has been
> >     encrypted to (if this is feasable to detect).
>
> We should change all Gpg4win frontends (like GpgOL, Kleo, GpgEX, GPA) 
> to honor the warnings and error messages that GnuPG already shows.

We use GPGME and GPGME honors GnuPG's warnings and error messages. To be 
honest I didn't really know about the importance of MDC when implementing 
decryption in GpgOL. But this shows again that as a frontend developer using 
GPGME makes it easy to stay secure as it just "does the right thing".

For Outlook 2007 and 2003 I think that the Problem is that back then GPGME was 
not used and the MDC Error got lost in communication through the middle man. 
(GPA / Kleopatra)

Please note that file encryption (Kleo or GPA) efail is not an issue and GpgEX 
does only call Kleo or GPA.


For S/MIME and GpgOL I think that showing only valid signed content is 
unfeasible. Even without the restriction that it should be signed by someone 
it is encrypted to.
There is just too much that could go wrong. You are offline, CRL / OCSP not 
available. You don't trust the root ca of the sender.  A sender want's to send 
something anonymously. There are incompatible implementations. There was a 
technical problem. etc.

Encryption is already to tricky and we should not make it more difficult to view 
encrypted data. I think that such a restriction would loose us users which 
will rather send stuff unencrypted and as such would lower the security.


Remember that as far as we know[1], the attacks rely on dynamic HTML features 
(e.g. loading of images) and this is generally a very bad Idea, especially for 
crypto mails. I rather think we should look into it if we can disable this for 
crypto, especially S/MIME mails first. Or at least show a warning if we detect 
that this is enabled in Outlook.


So my improvements for Gpg4win would be:

- Remove the vulnerable Outlook 2003 and 2007 support.
- Check if automatic loading of external data is enabled and warn when S/MIME 
is decrypted.
- Try to disable loading of external data when S/MIME is decrypted.


Best Regards,
Andre

[1]: There are unclear and vague hints in the paper about a CRL exfiltraction 
channel. We do not see any problem there and do not think that it is possible 
to exploit it, but we asked the authors to clarify.

-- 
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: 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/20180515/17295595/attachment.asc>


More information about the Gpg4win-devel mailing list