[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:firstname.lastname@example.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.