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

Re: Qualcom (and other) Android CVE IDs

Let me refine my statements.  It makes sense for a particular CNA to
require that a random researcher specify an impact, to validate that the
report is about a real issue.  However, it also makes sense for an
authoritative source to create a well-identified entry without an impact
being specified.  An example of an authoritative source would be a CNA
creating an entry about their own product.  The impact can be specified
elsewhere, e.g., in advisories, or although not ideal, not at all.  That
last case is a problem for scoring vulnerabilities in databases and for
vulnerability management, but it's out of the scope of the CVE.

I fear that requiring impact for all CVE entries might dissuade CNAs or
researchers from making the effort of having more or better
identification factors, or that it might result in fewer useful entries.
It should be possible to decouple validation and identification goals.

Pascal

On Wed, 2017-06-14 at 16:40 -0400, Art Manion wrote:
> On 2017-06-14 16:08, Pascal Meunier wrote:
> 
> > Identification is our mission;  source code commits are awesome for 
> > that
> > and in that case I'd suggest saying "but in (a) different (part of 
> > the)
> > code than CVE-... (commit links forthcoming)".  That would be
> > exceptionally good. 
> 
> Or name a function even, if that's an appropriate level of 
> abstraction at which to differentiate.
> 
> > I believe impact isn't necessary for identification, although it can
> > help.  Sometimes the impact can be up to someone with enough 
> > imagination
> > to get something else to happen.  So if we rely on impact as the 
> > only
> > thing differentiating a CVE from another, or a crucial (required)
> > identification factor, then the CVE entries could be on shifting
> > grounds.
> 
> Agree.  Identification (and sufficient de-duplication) is the main 
> goal, technical impact is (strongly?) preferred but optional.
> 
>  - Art
>
Page Last Updated or Reviewed: June 28, 2017