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

[David LeBlanc <dleblanc@microsoft.com>]

> -----Original Message-----
> From: aleph1@SECURITYFOCUS.COM [mailto:aleph1@SECURITYFOCUS.COM]

> * Steven M. Christey (coley@LINUS.MITRE.ORG) [000613 16:17]:
> > 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.
> >
> > 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.
 
> While sympathetic I agree with Bill. A patch really provides no
> strong "supporting evidence" that two vulnerabilities are the same
> except that the vendor decided to fix them at the same time.

When we release bulletins, we usually say whether the problems fixed are all
part of the same problem, or that we just happened to get 2 bugs in the same
area, so it was easier on everyone to release 1 hotfix for 2 problems.  I
would say that vendor input should be a strong determining factor on this
one, but that absent any vendor information we ought not make that
conclusive evidence.

Also, matters are pretty simple with respect to a hotfix, but a full service
pack could fix a large number of bugs, many of which may not be related.
This difference between a hotfix and a service pack is also specific to
Microsoft, and other people will probably do things differently.

To use the example of vendors who only cut new releases, then we have
additional complications - if there are code deltas between that version and
the previous version other than those associated with a patch, then we could
have a situation where unrelated bugs are also fixed or even caused by a
particular version change.