Re: assignments for malware

[Pascal Meunier <pmeunier@cerias.purdue.edu>]

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