danger of decrypted files without integrity protection
gdt at lexort.com
Thu May 17 21:48:28 CEST 2018
Steffen Nurpmeso <steffen at sdaoden.eu> writes:
> Greg Troxel <gdt at lexort.com> wrote:
> |Bernhard Reiter <bernhard at 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.)
More information about the Gnupg-devel