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

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

> From: Bill Fithen [mailto:wlf@cert.org]
 
> 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?).

This may seem to be fundamental, but practically it is more difficult than
that.  For example, say I have a bad DLL that exposes 10 symptoms, but the
cure is to update this one library.  I would say that the vulnerability is
the bad library, but that there are numerous possible exploits as a result.
The recent problem in the Linux kernel illustrates the issue.  So should we
issue several dozen CVE entries about apps that su because of one flaw in
certain Linux kernels?  Or should we issue one entry that says this one flaw
causes a lot of problems? I'll go for one entry.

The obvious problem we have is that we are not always able to determine
whether there is a single root cause, and that some vendors will just
release new binaries which may fix numerous problems, and not provide enough
information to determine what's going on under the covers.

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

We'll probably have to handle this on a case-by-case basis.  All the vendors
are different. Recent Microsoft bulletins have been fairly explicit about
whether a hotfix corrects related or unrelated issues, so it should be
fairly easy to deal with our products. For the rest of it, YMMV - you'll see
everything from very terse announcements with little to no information, all
the way up to knowing which line of code failed in which module.
 
> 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.

Again, I'd point out that perhaps "rules" is the wrong term to use and the
wrong approach. "Rules" implies a strict and inflexible process and if you
attempt to apply "rules" to a situation with a lot of noise, there will be a
lot of failures and/or the rules will become so complex that we'll need
lawyers to write and interpret them. Perhaps it is better to set forth goals
and guidelines. We can then use our collective judgement in order to try and
reach those goals on a case-by-case basis. It also gets us out of the
business of attempting to chart a decision tree that handles all possible
issues.
 
> 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.

I'd agree with this - but a merge doesn't entail irrevocable information
loss - we still have the original source reports, and we can still split
something later if we really need to.  We will probably err in both ways.
Page Last Updated or Reviewed: May 22, 2007