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

[Bill Fithen <wlf@cert.org>]

On Tue, 13 Jun 2000, David LeBlanc wrote:

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

It seems truly fundamental to me that the nature of a vulnerability is
independent of the mechanism(s) that can be used to correct it. There
may be many ways to correct a vulnerability. In fact, it seems obvious
to me that a "list" of such corrections of countermeasures is an
entirely separate undertaking on a par with CVE (perhaps CCE?).

If the goal of this rule is to help us split or merge based on what
the vendor says about his own product and there is no other way to
obtain that information than to infer it through the vendor's action,
I say that it makes no difference whether the vulnerabilities in
question are split or merged. We have so little information as to make
it useless.

I would rather have a rule that says that if the previous rules fail,
then we have to depend on the vendor of the product to say whether to
split or merge and just "live" with their response. We can never have
enough information (short of someone reverse engineering the affected
code) to make a meaningful split/merge decision.

All other things being inconclusive with respect to the split/merge
question, if we arrive at this rule and the vendor refuses to answer
the split/merge question, then it seems to me the only conservative
approach is to split. If we incorrectly split, the only consequence is
information redundancy. If we incorrectly merge, the consequence is
information loss. Once we split based on the lack of information, the
(possibly redundant) entries are marked as 'this is all we know' and
left that way until we know more. If at some point in the future (even
after they might be voted into CVE), if someone learns enough to
"prove" to us they should have been merged, then we merge them.

My guess is that few vendors of important software with meaningful
vulnerabilities will refuse to provide the necessary information. If
they do, then CVE or its board members as individuals can always
invoke the press on them.

Bill