[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: assignments for malware

On 8/13/18 12:55 PM, jericho wrote:


The second type is just a malicious module that has nothing to do with 
the legitimate module, other than a similar name as the means for 
getting people to download it. An example of that is CVE-2017-16044:

     `d3.js` was a malicious module published with the intent to hijack
     environment variables. It has been unpublished by npm.


This seems out of scope for CVE.  I get that npm-style software distribution is a 
"new" and real thing, and without having recently looked at it in 
detail, my impression is that npm and it's ecosystem isn't terribly secure, which 
is an intentional choice:

  
https://blog.npmjs.org/post/141702881055/package-install-scripts-vulnerability

In ancient box product terms, the analog is "I downloaded and linked 
lib-png.so because I wanted to include PNG support in my application."  Not 
a technical vulnerability, I accidentally installed malware.

Yes, these matter, and I'm in favor of telling the public about 
malicious npm-managed code, but that might not be CVE's job.

I don't see much of a difference with CVE-2018-3779.  Intentionally 
malicious code masquerading as legitimate, gains authority and 
reputation by being allowed on npm in the first place, depends on 
community to find and remove.

In terms of being vulnerabilities (and in scope for CVE), I'd say no, 
not in scope.  I wouldn't suggest removing any existing assignments, 
but either stop or make a decision to include such things in CVE's 
scope?

Trying out the other side: There is a (popular but insecure) software 
development ecosystem, within that system, flagging malicious 
components is treated like a vulnerability/CVE assignment?  Still 
doesn't really work for me.

 - Art
Page Last Updated or Reviewed: August 15, 2018