Re: [CD] CD Proposal: SF-LOC (Software flaws in different lines of code)

["Steven M. Christey" <coley@linus.mitre.org>]

Bill Fithen said:

>> *4) If P1 and P2 are not fixed by the same patch or set of patches,
>>     then they must remain SPLIT.
>

>I think this rule is inappropriate for CVE's purposes...  Vendors
>package software according to the rules of their business, not
>according to the technical content of the software...
>most of the ones following this one are focused on the nature of the
>vulnerability and the related software engineering practice that
>produced it. This rule is not.

I agree that this rule is less precise and reliable than the previous
ones.  However, while attempting to apply SF-LOC and SF-EXEC over the
past year while devloping CVE, there are *many* cases in which nobody
but the software vendor can really answer the question of whether or
not something is the same bug.  This problem is exacerbated by the
fact a lot of the software doesn't come with source code that one
could analyze, and the lack of detail is a significant bottleneck for
us when creating and reviewing candidates.  Thus some of these other
rules are trying to deal with that lack of information.

Casper Dik and David LeBlanc have effectively reinforced the
importance of the vendor in really understanding a problem.  See the
voting records on CAN-2000-0317 and CAN-1999-0818, for example:

  http://cve.mitre.org/cgi-bin/cvename.cgi?CAN-2000-0317
  http://cve.mitre.org/cgi-bin/cvename.cgi?CAN-1999-0818

For example, CAN-1999-0818 is reported as a problem in kcms_configure
in the original source as well as the Security Focus and X-Force
vulnerability databases, but Casper indicated that it's really a
library problem.  (This is not to be critical of those databases of
course, and the descriptions as written get the point across, but they
do omit a detail that could be useful in the "deep analysis" that's
required to *really* understand the nature of the problem.)

We can't get this level of participation (and honesty?) from every
vendor.  Since I started recording vendor acknowledgement in CMEX,
almost HALF of the active candidates don't even have any concrete
acknowledgement from the vendor.  And as we all know, some vendors
publish extremely sparse advisories with no details at all.

So some of these rules, while moving away from looking at the bug
itself, are designed to find "supporting evidence" that will help us
to make a reasonably explainable (and repeatable) decision in the
absence of good facts.  That said, the fact that patches are
implemented differently might require at least a reordering of the
"evidence" rules.

- Steve