#eFail is #reFail

Herminio Hernandez, Jr. herminio.hernandezjr at gmail.com
Mon May 14 16:18:36 MST 2018


So it looks like a good way to send secure message is write them as text
files, encrypt them via GPG and send as attachments. Am I right?

On Mon, May 14, 2018 at 3:52 PM, Joseph Sinclair <plug-discussion at stcaz.net>
wrote:

> The EFF recommendation is primarily an abundance of caution for the
> community who use PGP for mail as many such users are at risk of serious
> and targeted attack.
> PGP being enabled won't open a threat vector for some other attack.
> Having it enabled in email may, however, allow a targeted attack to expose
> the decrypted content of those emails; so for now (if you have very
> high-value encrypted emails) it may be better to export PGP email and
> decrypt at the command line for reading in a text editor.
>
> TL;DR
> Overall this is a class of attacks that could expose the plain text of
> emails encrypted with S/MIME or PGP, but requires enough effort and skill
> that it's mostly an issue for individuals who are using PGP or S/MIME to
> defend against serious threats, such as criminal organizations or state
> actors, and have emails containing sufficient value to justify the level of
> effort involved.
> All users should disable HTML in email by default, regardless, as that is
> a major attack vector that has no known mitigation (and likely never will),
> HTML may be enabled for individual (unencrypted) messages as needed.
> Encrypted email should, of course, never be anything other than plain text
> (with separately encrypted attachments if needed).
>
> Below is my (admittedly limited) full assessment for those who might be
> interested.
>
> The vulnerabilities requires two major factors:
> 1) The attacker must have the original encrypted message (the ciphertext)
> still encrypted.  These are most concerning as Man-in-the-Middle attacks.
> 2) The client must (generally) have HTML email supported and enabled
> (note, HTML isn't the only backchannel available, but it's the most likely
> and by far the easiest to implement).
>
> Note that all of these techniques export some amount of the decrypted
> data, but not a massive amount.  Somewhere between 4 and 200 bytes.  They
> can be repeated, however, within a final multipart MIME email to obtain the
> full text.
>
> How it works, in short form:
> If you have HTML enabled on view, the attacker can send you a message in
> HTML format with the ciphertext buried within the HTML (e.g. inside the
> href attribute of a img tag), and use url packing (putting tracking text in
> a URL after the resource path) to send that text to a server.  The client
> will happily decrypt the contents, then attempt to access the url, sending
> the decrypted data to the server as part of the request.
> If you have one of the HTML email clients (e.g. most webmail clients) that
> allow script within the email, then a script could easily send the *entire*
> decrypted content to the server, and then display *only* that to the user;
> successfully hiding its tracks while obtaining the full decrypted message.
> Webmail clients should probably never be used with PGP or S/MIME.
>
> What the attacker does is grab the encrypted message, modify it to take
> advantage of one of the discussed techniques, and then forward it on to the
> intended recipient.
> In the simplest case, the attacker just wraps the content in properly
> structured HTML (ideally with script) and adjusts the MIME structure, then
> send it on.  If HTML is enabled, this can be enough.
> If a more advanced approach is required (and script isn't available), then
> the data can be restructured in several ways using flaws in specific block
> encryption modes (specifically CBC and CFB) to obtain small amounts of data
> in each MIME part; repeating the attack enough times to get most or all of
> the data (up to around 500 MIME parts).  The message looks funny, and might
> be suspicious, but it still has a decent chance of working.
> With even more effort, a non-HTML backchannel might be used, something
> like MIME external data blocks and DNS sniffing, or PGP key lookups, but
> the amount of data obtained in this way will be quite limited.
>
> GPG includes certain mechanisms to prevent the more difficult attacks
> against the OpenPGP specification, although it cannot do much about a leaky
> client.  Not all clients enable those features or respond to reported
> security issues properly, however, so while GPG is (or can be) secure, its
> use in email may not be, depending on the client.
> Some mail gateways that apply encryption at the gateway are vulnerable,
> although most can be configured to be secure, and some are secure in the
> default configuration (details for these are not provided, of course).
>
> On 2018-05-14 01:58 PM, Herminio Hernandez, Jr. wrote:
> > So this why the EFF is recommending this
> > https://www.eff.org/deeplinks/2018/05/disabling-pgp-thunderbird-enigmail
> >
> > On Mon, May 14, 2018 at 1:24 PM, der.hans <PLUGd at lufthans.com> wrote:
> >
> >> moin moin,
> >>
> >> lots of news about "new" PGP and S/MIME handling security issues.
> >>
> >> Considering GnuPG addressed it 15 years ago, it doesn't seem to be new
> :)
> >>
> >> Also, email clients automatically displaying remote content has never
> >> been safe.
> >>
> >> Summary seems to be:
> >>
> >> 1. Using text mail rather than html mail mitigates one of the disclosed
> >> issues.
> >>
> >> 2. Disabling old ciphers or having a mail client that properly handles
> >> decryption warnings and/or sanitizes messages will work for the other.
> >>
> >> See mailpile's response for the latter.
> >>
> >> https://lists.gnupg.org/pipermail/gnupg-users/2018-May/060315.html
> >>
> >> https://www.mailpile.is/blog/2018-05-14_PGP_Security_Alert.html
> >>
> >> One good thing to come out of this is that I now know about mailpile :)
> >>
> >> ciao,
> >>
> >> der.hans
> >> --
> >> #  https://www.LuftHans.com   https://www.PhxLinux.org
> >> #  Eternal vigilance is the price of liberty. -- Thomas Jefferson
> >> ---------------------------------------------------
> >> PLUG-discuss mailing list - PLUG-discuss at lists.phxlinux.org
> >> To subscribe, unsubscribe, or to change your mail settings:
> >> http://lists.phxlinux.org/mailman/listinfo/plug-discuss
> >
> >
> >
> > ---------------------------------------------------
> > PLUG-discuss mailing list - PLUG-discuss at lists.phxlinux.org
> > To subscribe, unsubscribe, or to change your mail settings:
> > http://lists.phxlinux.org/mailman/listinfo/plug-discuss
> >
>
>
> ---------------------------------------------------
> PLUG-discuss mailing list - PLUG-discuss at lists.phxlinux.org
> To subscribe, unsubscribe, or to change your mail settings:
> http://lists.phxlinux.org/mailman/listinfo/plug-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.phxlinux.org/pipermail/plug-discuss/attachments/20180514/619ff22f/attachment.html>


More information about the PLUG-discuss mailing list