Hi,
On 11/29/15 11:20 AM, Walter H. wrote:
> I'd say this is the wrong answer, this can be done alternativly as
> used to do
> (pushing an encrypted .rar or .zip is exactly this use case with
> advantage,
> there is no implicit malware impact ...)
>
> for security reason exactly this way you mentioned must be forbidden;
> there mustn't be a way pushing malware to a server,
> which the server itself has no possibility to clean it ...
I have to agree that this is a big issue. Here's the problem: we like
to say that we would devolve the responsibility to the end user who is
pushing the file. The problem occurs when the end user who is pushing
the file has been broken into and her credentials have been stolen.
That's the classic BOTnet model. And so this poses a new vector that
wasn't there before.
But I would suggest that there are mitigations to this attack, one such
being that the content is attested to by a malware protection system
(McAfee, Kaspersky, etc) such that server might trust it, and might
otherwise reject such content.
In as much as we can have the discussion as to how to mitigate the
attack, I'm +1 for adopting. Otherwise -1.
Eliot