danger of decrypted files without integrity protection

[Greg Troxel]

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.)