再保险(CD): CD建议:SF-LOC(软件缺陷在不同的行代码)

在星期二,2000年6月13日,大卫李布朗写道:> > - - - - -原始消息- - - - - - > >:aleph1@SECURITYFOCUS。COM (mailto: aleph1@SECURITYFOCUS.COM]> > > * Steven m . Christey (coley@LINUS.MITRE.ORG)[000613] 16:17:比尔Fithen说:> > > > > > > > > > > * 4)如果不固定,P1和P2相同的补丁,补丁或设置> > > > > > >之后,他们必须保持分裂。> > > > > > > > > > >我觉得这个规则不适合CVE的目的……供应商> > > >包软件根据其业务规则,而不是> > > >根据软件的技术内容……> > > >最下面的是关注> > > > > >脆弱性的性质和相关的软件工程实践> > > >。这个规则不是。> > > > > >所以这些规则,而远离看着虫子> > >本身,是为了找到“证据”,将帮助我们> > >做出合理解释和可重复的决定> > >中缺乏良好的事实。说,补丁> > >实现不同可能需要至少一个重新排序的> > >“证据”的规则。> > >而同情我同意法案。一个补丁真的没有提供> >强大的“证据”,两个漏洞是相同的> >除了供应商决定同时修复它们。> >当我们发布公告,我们通常说的问题是否固定都>同样的问题的一部分,或者,我们只是碰巧得到2缺陷在同一>区域,所以对每个人释放1次2的问题。 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