Re: assignments for malware

[Kurt Seifried <kurt@seifried.org>]

On Mon, Aug 13, 2018 at 2:01 PM, Pascal Meunier <pmeunier@cerias.purdue.edu> wrote:

On Mon, 2018-08-13 at 14:44 -0500, jericho wrote:
> On Mon, 13 Aug 2018, Kurt Seifried wrote:
>
> : Depending on how the names are parsed and how the namespace is managed (or
> : not) it can actually be attacked in some cases, through automated
> : dependancy resolvers. And again, if there's malicious code being
> : distributed and used is there some specific reason we don't want to tell
> : people about it, and would rather ignore it?  

>
> The quick answer is 'yes', volume alone. Trying to track any site 
> distributing malware would be extensive to say the least.
>

Good point.  I would add that things installed through deception are more the domain of
social engineering than software engineering.  If automated dependancy resolvers can be
made to install such things, then I'd say the vulnerability resides in the resolvers, and
I don't care about each of the large number of things that could potentially be installed.

Well for example:

https://blog.npmjs.org/post/141577284765/kik-left-pad-and-npm

so apparently I can register a company called JSON, hijack the json NPM and... take over the world. Vulnerable code, vulnerable business processes, etc. but I think in general we'd be better off covering things that matter rather than ignoring the world outside of boxed software that ships to a customer. 

 

We sure want people to know about security issues that are relevant to them.  However, I'd
say malware instances are out of scope of the CVE, whereas flaws that allow malware
installation are in scope.  The malware isn't the flaw.

So this means any developer can then DISPUTE and cause a CVE to be REJECT'ed by simply by saying "that buffer overflow was on purpose, it was a hidden backdoor" which sounds ridiculous but is a logical outcome of such a decision. I'm pretty sure that's not what we want.

 

Pascal

--

Kurt Seifried
kurt@seifried.org