Re: assignments for malware

[Kurt Seifried < kurt@seifried.org >]

The NPM problems aren’t new, CPAN had (and still has) many of the same
problems.


-Kurt





> On Aug 13, 2018, at 15:19, Art Manion <amanion@cert.org> wrote:
>
>> 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
>