assignments for malware

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

assignments for malware

jericho

Board,

This year there have been an increasing number of CVE assignments for
malware; specifically 'malicious ruby gems' or 'malicious NPM modules'.
They potentially come in two varieties, and may be handled differently
depending. The first, and recent is CVE-2018-3779:

  active-support ruby gem 5.2.0 could allow a remote attacker to
  execute arbitrary code on the system, caused by containing a
  malicious backdoor. An attacker could exploit this vulnerability
  to execute arbitrary code on the system.

It isn't crystal clear from the H1 report if this was the legitimate code
being backdoored, similarly named gem via a forked project, or a gem being
distributed with a similar name (which I suspect). "The gem duplicates
official activesupport (no hyphen) code, but adds a compiled extension."

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 is essentially malware, just served up via an official repository.
Since that does not represent a vulnerability in a piece of software, it
is my understanding that this would not meet the criteria for inclusion in
CVE.

Could MITRE clarify the policy on this?

Thank you,

Brian

Reply | Threaded
Open this post in threaded view
|

Re: assignments for malware

Kurt Seifried-2


On Mon, Aug 13, 2018 at 10:55 AM, jericho <[hidden email]> wrote:

Board,

This year there have been an increasing number of CVE assignments for malware; specifically 'malicious ruby gems' or 'malicious NPM modules'. They potentially come in two varieties, and may be handled differently depending. The first, and recent is CVE-2018-3779:

        active-support ruby gem 5.2.0 could allow a remote attacker to
        execute arbitrary code on the system, caused by containing a
        malicious backdoor. An attacker could exploit this vulnerability
        to execute arbitrary code on the system.

It isn't crystal clear from the H1 report if this was the legitimate code being backdoored, similarly named gem via a forked project, or a gem being distributed with a similar name (which I suspect). "The gem duplicates official activesupport (no hyphen) code, but adds a compiled extension."

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 is essentially malware, just served up via an official repository. Since that does not represent a vulnerability in a piece of software, it is my understanding that this would not meet the criteria for inclusion in CVE.

A backdoor is a vulnerability. I think the problem is CVE in past dealt with "oops we make a mistake" and not "oops, a malicious actor did it on purpose". 

Doesn't matter to the end user, well actually it does, backdoors are worse because someone for sure knows about the vulnerability and most likely intended to use it. So do these things need CVEs, tracking and remediation for people affected by it? Yes. 

I'm trying to imagine a scenario where a software or service user goes "oh, this exploitable flaw is a backdoor, thus no CVE, thus we don't need to remediate it" and uhh.. I can't imagine that, not even close. 
 

Could MITRE clarify the policy on this?

Thank you,

Brian




--
Kurt Seifried
[hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: assignments for malware

jericho

On Mon, 13 Aug 2018, Kurt Seifried wrote:

: A backdoor is a vulnerability. I think the problem is CVE in past dealt
: with "oops we make a mistake" and not "oops, a malicious actor did it on
: purpose".
:
: Doesn't matter to the end user, well actually it does, backdoors are
: worse because someone for sure knows about the vulnerability and most
: likely intended to use it. So do these things need CVEs, tracking and
: remediation for people affected by it? Yes.
:
: I'm trying to imagine a scenario where a software or service user goes
: "oh, this exploitable flaw is a backdoor, thus no CVE, thus we don't
: need to remediate it" and uhh.. I can't imagine that, not even close.


Granted. But a malicious module that has a similar name as another isn't a
backdoor.
Reply | Threaded
Open this post in threaded view
|

Re: assignments for malware

Kurt Seifried-2
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? I think reducing the scope of coverage of CVE doesn't make much sense, especially in the modern world with how agile-hyper-dev-sec-ops-scrum (I don't know what the terms are anynmore so just making a single large one) is actually using a lot of this stuff in ways that ignore pretty much everything except for CVEs when it comes to problems. 

On Mon, Aug 13, 2018 at 1:31 PM, jericho <[hidden email]> wrote:

On Mon, 13 Aug 2018, Kurt Seifried wrote:

: A backdoor is a vulnerability. I think the problem is CVE in past dealt
: with "oops we make a mistake" and not "oops, a malicious actor did it on
: purpose".
:
: Doesn't matter to the end user, well actually it does, backdoors are
: worse because someone for sure knows about the vulnerability and most
: likely intended to use it. So do these things need CVEs, tracking and
: remediation for people affected by it? Yes.
:
: I'm trying to imagine a scenario where a software or service user goes
: "oh, this exploitable flaw is a backdoor, thus no CVE, thus we don't
: need to remediate it" and uhh.. I can't imagine that, not even close.


Granted. But a malicious module that has a similar name as another isn't a
backdoor.



--
Kurt Seifried
[hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: assignments for malware

jericho

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.

Reply | Threaded
Open this post in threaded view
|

Re: assignments for malware

Pascal Meunier
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.

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.

Pascal

Reply | Threaded
Open this post in threaded view
|

Re: assignments for malware

Kurt Seifried-2


On Mon, Aug 13, 2018 at 2:01 PM, Pascal Meunier <[hidden email]> 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:


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
[hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: assignments for malware

Art Manion
In reply to this post by jericho
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

Reply | Threaded
Open this post in threaded view
|

Re: assignments for malware

Kurt Seifried-2
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 <[hidden email]> 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
>

Reply | Threaded
Open this post in threaded view
|

Re: assignments for malware

Pascal Meunier
In reply to this post by Kurt Seifried-2
On Mon, 2018-08-13 at 14:10 -0600, Kurt Seifried wrote:

> On Mon, Aug 13, 2018 at 2:01 PM, Pascal Meunier <[hidden email]>
> 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.

I worry about everything looking like a nail because we have a hammer.  Other tools may be
more appropriate.

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

I meant to address distinct malware from a 3rd party (the "second type" in Brian's post),
which seemed your concern when talking about dependency resolvers.  When a vendor
integrates malware into a product, the intention of the vendor is irrelevant, and the
vendor doesn't get to redefine words.  

I believe that whether a violation happens in the scope of the code or not, compared to
the legitimate purpose of the code, is what makes it relevant, in scope for a CVE or not.
Phishing web sites and emails shouldn't get CVEs.  Pure malware shouldn't get CVEs.
However, if you buy a well-known, reputed AV product that contains vulnerabilities that
may or may not have been put in intentionally and may or may not have been put in by a
third party, that is in scope for a CVE.  If you go to a curated app store that is
supposed to contain only trustworthy apps, and install one later discovered to be
malicious, a CVE could help and is in scope, in addition to an advisory and action by the
vendor and curator.  

Regardless of the wisdom of using code from uncurated repositories (npm or such), a CVE
appears appropriate on the presumption and representation that the vulnerable code serves
a legitimate purpose, if the vulnerability is the result of a code flaw.  That's in scope.
 The fact that code could be pulled isn't a vulnerability in the code that's in the
repository.  A product depending on the repository service being available and unchanged
is a risky product;  however it's not always obvious if it's in scope or out of scope of
the CVE.  I'm inclined to think that remote code availability and integrity issues are in
scope for the CVE only if the software that includes it, makes representations that it is
handling those issues securely.  Vulnerabilities from business processes or misplaced
trust are real, but violations that occur out of scope of the code should likely be out of
scope of the CVE, unless the code is expected to handle them somehow.

As to our previous discussion topic,  smart contracts, CVEs appear in scope because the
code should handle the vulnerable scenarios, regardless of whether vulnerable versions
were seeded in the hope of getting someone rich to use them, or simply the result of
mistakes.

Pascal

 


>
>
> >
> > Pascal
> >
>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: assignments for malware

Millar, Thomas
Are people going to find out about and fix these issues in their environment without a CVE? In other words, will a malware indicator do the job? If so, then it doesn’t need to be in scope.

Sent from📱: <a href="tel:202-631-1915" dir="ltr" x-apple-data-detectors="true" x-apple-data-detectors-type="telephone" x-apple-data-detectors-result="3" style="background-color: rgba(255, 255, 255, 0); font-size: 13pt;">202-631-1915


On Aug 13, 2018, at 18:55, Pascal Meunier <[hidden email]> wrote:

On Mon, 2018-08-13 at 14:10 -0600, Kurt Seifried wrote:
On Mon, Aug 13, 2018 at 2:01 PM, Pascal Meunier <[hidden email]>
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.

I worry about everything looking like a nail because we have a hammer.  Other tools may be
more appropriate.




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.

I meant to address distinct malware from a 3rd party (the "second type" in Brian's post),
which seemed your concern when talking about dependency resolvers.  When a vendor
integrates malware into a product, the intention of the vendor is irrelevant, and the
vendor doesn't get to redefine words.  

I believe that whether a violation happens in the scope of the code or not, compared to
the legitimate purpose of the code, is what makes it relevant, in scope for a CVE or not.
Phishing web sites and emails shouldn't get CVEs.  Pure malware shouldn't get CVEs.
However, if you buy a well-known, reputed AV product that contains vulnerabilities that
may or may not have been put in intentionally and may or may not have been put in by a
third party, that is in scope for a CVE.  If you go to a curated app store that is
supposed to contain only trustworthy apps, and install one later discovered to be
malicious, a CVE could help and is in scope, in addition to an advisory and action by the
vendor and curator.  

Regardless of the wisdom of using code from uncurated repositories (npm or such), a CVE
appears appropriate on the presumption and representation that the vulnerable code serves
a legitimate purpose, if the vulnerability is the result of a code flaw.  That's in scope.
The fact that code could be pulled isn't a vulnerability in the code that's in the
repository.  A product depending on the repository service being available and unchanged
is a risky product;  however it's not always obvious if it's in scope or out of scope of
the CVE.  I'm inclined to think that remote code availability and integrity issues are in
scope for the CVE only if the software that includes it, makes representations that it is
handling those issues securely.  Vulnerabilities from business processes or misplaced
trust are real, but violations that occur out of scope of the code should likely be out of
scope of the CVE, unless the code is expected to handle them somehow.

As to our previous discussion topic,  smart contracts, CVEs appear in scope because the
code should handle the vulnerable scenarios, regardless of whether vulnerable versions
were seeded in the hope of getting someone rich to use them, or simply the result of
mistakes.

Pascal

 





Pascal





Reply | Threaded
Open this post in threaded view
|

Re: assignments for malware

Art Manion
On 2018-08-14 17:37, Millar, Thomas wrote:
> Are people going to find out about and fix these issues in their environment without a CVE? In other words, will a malware indicator do the job? If so, then it doesn’t need to be in scope.

Arguing mostly against myself, a CVE ID may well raise attention, which is desirable.

The problem is opening the scope of CVE too widely.  Maybe an "exposure" is that I thought some software was legit, but turns out it was not?  As opposed to something that is clearly malware from the start?

We have a lot of malware to assign CVE IDs to.

 - Art