Re: assignments for malware

["Millar, Thomas" <Thomas.Millar@hq.dhs.gov>]

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📱: 202-631-1915

On Aug 13, 2018, at 18:55, Pascal Meunier <pmeunier@cerias.purdue.edu> wrote:

On Mon, 2018-08-13 at 14:10 -0600, Kurt Seifried wrote:

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.

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