Mailing List Archive

danger of decrypted files without integrity protection
Pondering how dangerous manipulated decrypted files are
I've done the following experiment on a GNU system:

echo "File loading external references? Yes, if you can see the following image: <img src=https://gnupg.org/share/logo-gnupg-light-purple-bg.png />" >test.html
firefox test.html
chromium test.html

both times the image was shown.

dpkg -s firefox-esr chromium | grep Version
Version: 52.8.0esr-1~deb9u1
Version: 66.0.3359.117-1~deb9u1

Even if the originally encrypted file was something else,
it could be wrapped into html by an attacker
and even if the browser's SOP would not allow to load external
references listed in local file by default, you could additionally
try adding one of the https://en.wikipedia.org/wiki/Same-origin_policy#Relaxing_the_same-origin_policy
methods that work on a local file.

Seems decrypted files that had no integrity protection are
dangerous because they could be manipulated to send decrypted
plaintext anyware once the users opens them.

Best Regards,
Bernhard

--
www.intevation.de/~bernhard ? +49 541 33 508 3-3
Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998
Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
Re: danger of decrypted files without integrity protection [ In reply to ]
Am 17.05.2018 um 10:26 schrieb Bernhard Reiter:
> Pondering how dangerous manipulated decrypted files are
> I've done the following experiment on a GNU system:
>
> echo "File loading external references? Yes, if you can see the following image: <img src=https://gnupg.org/share/logo-gnupg-light-purple-bg.png />" >test.html
> firefox test.html
> chromium test.html
>
> both times the image was shown.
>
> [...]
>
> Seems decrypted files that had no integrity protection are
> dangerous because they could be manipulated to send decrypted
> plaintext anyware once the users opens them.
>
> Best Regards,
> Bernhard
As far as I understand efail, there are two variants.

1st variant is attacking plain or multipart encrypted messages
by wrapping them into a multipart message, which afterwards
causes the mai client to leak the decrypted content.
- For this variant there is not much GnuPG can do, as long as
its scope remains confined to encrypted message bodies and
mail parts. The 'proper' way to fix this would be fixing the mail
clients to strictly respect boundaries between parts of multipart
messages.

2nd variant is attacking CFB mode by injecting CFB gadgets that
decrypt to some markup, which cause the mail client to leak
decrypted content. This should be easily prevented by proper
signature verification as the gadget injection leads to modified
plaintext.
- email clients should guide users to use encryption only with
signed contents AND verify the signatures before parsing the mail.
- GnuPG could refuse (or: require --force) to encrypt without signing,
but this might also break other existing legitimate use cases.
- CFB/CBC could be replaced in the standard by operation modes that
are not vulnerable to gadget injection. But we still would need to
support legacy modes for old encrypted mail decryption for a while...

I'd object GnuPG to generally interpret email message formats, also
because we cannot gracefully handle suspicious results.

Beyond that, I could imagine a more secure email transport protocol,
which generally prohibits any modification of documents by attackers.
This can be achieved by true and mandatory end-to-end encryption
and content signing.

Regards
??? Holger
Re: danger of decrypted files without integrity protection [ In reply to ]
On 17/05/18 10:18, Holger Smolinski wrote:
> 2nd variant is attacking CFB mode by injecting CFB gadgets that
> decrypt to some markup, which cause the mail client to leak
> decrypted content. This should be easily prevented by proper
> signature verification as the gadget injection leads to modified
> plaintext.

We need to be careful here to distinguish signatures (that declare an
identity) from integrity protection. Signatures are not required for
integrity, and in many cases are not desirable because they break
anonymity. Integrity protection such as AE and MDC are perfectly good
solutions that don't require a pubkey signature. AE is the "proper" way
to do it as integrity failures can be detected sooner in the decryption
process, but MDC (IFF handled properly by the calling program, which
admittedly is not always the case) is a reasonable fallback.

The solution that we've all known about for ages is to get authenticated
encryption into the standard, but that's not going to happen tomorrow.

--
Andrew Gallagher
Re: danger of decrypted files without integrity protection [ In reply to ]
Am Donnerstag 17 Mai 2018 11:18:40 schrieb Holger Smolinski:
> 2nd variant is attacking CFB mode by injecting CFB gadgets

The CFB mode with MDC as GnuPG is using by default for 15 years
protects against this. (As discussed in other posts already.)

The point of my post is that the CBC mode that all known
CMS implementations use for S/MIME does not have this protection
for emails without inner signature.
So files coming out of this can leak decrypted plaintext
or otherwise use a backchannel or get "active".

Browsers offer no additional protection. So decrypting
files outside an email client may lead to dangerous files.

Bernhard

--
www.intevation.de/~bernhard   +49 541 33 508 3-3
Intevation GmbH, Osnabrück, DE; Amtsgericht Osnabrück, HRB 18998
Geschäftsführer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
Re: danger of decrypted files without integrity protection [ In reply to ]
Bernhard Reiter <bernhard@intevation.de> writes:

> Pondering how dangerous manipulated decrypted files are
> I've done the following experiment on a GNU system:
>
> echo "File loading external references? Yes, if you can see the following image: <img src=https://gnupg.org/share/logo-gnupg-light-purple-bg.png />" >test.html
> firefox test.html
> chromium test.html
>
> both times the image was shown.

In your example, you asked a browser to render html, which has different
norms than rendering incoming (and hence not requested by the user)
email. Even a relatively paranoid browser with uMatrix will render
images from different origins.

If you are calling decrypted content without integrity protection (and
probably, without Data Origin Authenication) protection dangerous, why
are you not also calling unencrypted unauthenticated content dangerous?

The larger real issue here is treating incoming bits as a program and
interpreting it (to include fetching remote content), rather than simply
displaying it.

Mail use of html should not fetch images (which are also likely to
contain tracking identifiers) or execute javascript.

(This is all separate from the discussion about combining multiple
arriving html documents into one document for rendering.)

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-devel
Re: danger of decrypted files without integrity protection [ In reply to ]
Am Donnerstag 17 Mai 2018 15:05:35 schrieb Greg Troxel:
> In your example, you asked a browser to render html, which has different
> norms than rendering incoming (and hence not requested by the user)
> email.  Even a relatively paranoid browser with uMatrix will render
> images from different origins.

It is a detail to the questions:
* is decrypting an email manually outside of a mailer safe?
-> no - for files that potentially will call home on opening
* do webbrowsers follow external links when coming from local disk?
-> yes (in the sample)



--
www.intevation.de/~bernhard   +49 541 33 508 3-3
Intevation GmbH, Osnabrück, DE; Amtsgericht Osnabrück, HRB 18998
Geschäftsführer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
Re: danger of decrypted files without integrity protection [ In reply to ]
Bernhard Reiter <bernhard@intevation.de> writes:

> Am Donnerstag 17 Mai 2018 15:05:35 schrieb Greg Troxel:
>> In your example, you asked a browser to render html, which has different
>> norms than rendering incoming (and hence not requested by the user)
>> email.  Even a relatively paranoid browser with uMatrix will render
>> images from different origins.
>
> It is a detail to the questions:
> * is decrypting an email manually outside of a mailer safe?
> -> no - for files that potentially will call home on opening

Decrypting is not the problem. The problem is evaluating the file
either with a program that interprets it and does unsafe things, or that
is exploitable (e.g. because it is buggy, perhaps because the format is
too complicated). All of these issues are also present with handling
files that were not recently decrypted.



_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-devel
Re: danger of decrypted files without integrity protection [ In reply to ]
Greg Troxel <gdt@lexort.com> wrote:
|Bernhard Reiter <bernhard@intevation.de> writes:
|> Am Donnerstag 17 Mai 2018 15:05:35 schrieb Greg Troxel:
|>> In your example, you asked a browser to render html, which has different
|>> norms than rendering incoming (and hence not requested by the user)
|>> email.  Even a relatively paranoid browser with uMatrix will render
|>> images from different origins.
|>
|> It is a detail to the questions:
|> * is decrypting an email manually outside of a mailer safe?
|> -> no - for files that potentially will call home on opening
|
|Decrypting is not the problem. The problem is evaluating the file
|either with a program that interprets it and does unsafe things, or that
|is exploitable (e.g. because it is buggy, perhaps because the format is
|too complicated). All of these issues are also present with handling
|files that were not recently decrypted.

Not being able to detect that injections happened because
decrypting silently succeeds because of missing i.-p. is the
problem on the S/MIME side (isn't it).

--steffen
|
|Der Kragenbaer, The moon bear,
|der holt sich munter he cheerfully and one by one
|einen nach dem anderen runter wa.ks himself off
|(By Robert Gernhardt)

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-devel
Re: danger of decrypted files without integrity protection [ In reply to ]
Steffen Nurpmeso <steffen@sdaoden.eu> writes:

> Greg Troxel <gdt@lexort.com> wrote:
> |Bernhard Reiter <bernhard@intevation.de> writes:
> |> Am Donnerstag 17 Mai 2018 15:05:35 schrieb Greg Troxel:
> |>> In your example, you asked a browser to render html, which has different
> |>> norms than rendering incoming (and hence not requested by the user)
> |>> email.  Even a relatively paranoid browser with uMatrix will render
> |>> images from different origins.
> |>
> |> It is a detail to the questions:
> |> * is decrypting an email manually outside of a mailer safe?
> |> -> no - for files that potentially will call home on opening
> |
> |Decrypting is not the problem. The problem is evaluating the file
> |either with a program that interprets it and does unsafe things, or that
> |is exploitable (e.g. because it is buggy, perhaps because the format is
> |too complicated). All of these issues are also present with handling
> |files that were not recently decrypted.
>
> Not being able to detect that injections happened because
> decrypting silently succeeds because of missing i.-p. is the
> problem on the S/MIME side (isn't it).

Yes, that is a problem -- thinking you have integrity protection when
you don't. I suspect, though, that almost everyone with that problem is
accepting unencrypted mail also.

So I didn't mean to suggest that there was nothing to fix -- only that
"processing decrypted files is dangerous" is a subset of "processing
files is dangerous".

Even with integrity/dao protection, the notion that an authorized sender
could not have sent a malicous file is an unwarranted conclusion --
certainly their machine could have been compromised, or they could have
got it from somewhere else. (I'm not sure if that notion is wrapped up
in this discussion or not.)

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-devel
Re: danger of decrypted files without integrity protection [ In reply to ]
Am Donnerstag 17 Mai 2018 21:48:28 schrieb Greg Troxel:
> I didn't mean to suggest that there was nothing to fix -- only that
> "processing decrypted files is dangerous" is a subset of "processing
> files is dangerous".

I disagree. What efails reminds us of is that a decrypted
file may contain cleverly placed pieces that will send a decrypted contents
somewhere else, so it is more problematic because it may expose
something that was intented to be kept confidential.

If the decryption client will decrypt several different message parts in one
go, then it could even be tricked to decrypt several messages parts.

Bernhard
--
www.intevation.de/~bernhard   +49 541 33 508 3-3
Intevation GmbH, Osnabrück, DE; Amtsgericht Osnabrück, HRB 18998
Geschäftsführer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
Re: danger of decrypted files without integrity protection [ In reply to ]
Hi,

On Fri, 2018-05-18 at 09:08 +0200, Bernhard Reiter wrote:
> Am Donnerstag 17 Mai 2018 21:48:28 schrieb Greg Troxel:
> > I didn't mean to suggest that there was nothing to fix -- only that
> > "processing decrypted files is dangerous" is a subset of "processing
> > files is dangerous".
>
> I disagree. What efails reminds us of is that a decrypted
> file may contain cleverly placed pieces that will send a decrypted
> contents
> somewhere else, so it is more problematic because it may expose
> something that was intented to be kept confidential.
But that's exactly what makes it a subset of the more general problem as
per the email before.
So I can't see where your disagreement comes from.

Cheers,
Tobi

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-devel