再保险:[技术]CD:模糊(模糊的供应商的描述漏洞)

>从:史蒂文·m·Christey [mailto: coley@linus.mitre.org]>亚当Shostack说:> > >我不确定的存在供应商补丁应该接受> >解决这些问题;看到最近的Internet explorer上卷> >补丁。,这是第一次采取了一些供应商不止一个试图真正补丁整个问题?>注意斜方非常小心假设一个咨询修复>特定问题。CVE改进之道,我引用大量>内容团队,问道:“如果有人声称确认>供应商说什么或说谜语,然后问题一直>固定?”Ah, but we're not very careful to make sure that a problem actually _exists_ before assigning a CAN to it. There's noise on both ends of the process. So we should complain about vendors not supplying you with test exploits and extremely detailed information, but not complain about vague, poorly written and unreproducible vuln reports that end up in the CVE? If we're going to start griping about vagueness, let's gripe about all the vagueness problems, not just some of them. >Basically, without clear evidence that the vendor is addressing >a specific issue, we don't add it as a reference to a candidate/entry >that it might be addressing. So what constitutes clear evidence? This one gets complicated - for example, Georgi finds some weird problem in IE, describes it in a rambling post, says "suppose" other versions might be vulnerable. So then we go figure it out, fix what he complains about, check as many of the "suppose" conditions as possible, find and fix several other issues found at the same time, and ship a patch. Since Georgi never gives us a reasonable amount of time to fix things, we never acknowledge him in the bulletin. >Depending on how circumstantial the evidence, we may create a separate >item for it and note the possible duplication in the analysis section, >or I might cast a REVIEWING vote on the possible duplicate candidate and >note the vague reference. So we're going to have CANs that don't neccesarily refer to an exploit? This makes sense, as many security tools do check for just patch installation, and sometimes service pack level. We can't have one vendor calling it the windows.foobar.i.dont.know.patch.008 check, and another calling it something different. >A great example of this is the classic phrase "fixed security bug," >which you find scattered throughout change logs from a variety of open >and closed source, commercial and freeware vendors. Without at least a >closely-correlated date and some credits to the person who announced the >problem to Bugtraq, we normally don't call this sufficient >acknowledgement, and the "vendor acknowledgement" data field has an >"unknown vague" value in it, which is available to voters. Ah - the Theo problem... I see. IMHO, either the vendor has acknowledged the bug or it hasn't. I'd just make this one binary. If it says the vendor didn't acknowlege the bug, let them complain and point out which patch fixed it, in which case you now have a solid acknowlegement. (I have a fear I have just created work for myself, but...) >There are about 15 candidates whose acknowledgement is "unknown vague," >but there are about 100 candidates whose acknowledgement is "unknown >discloser-claimed" - where the person announcing the problem says that >the vendor fixed the issue and/or provided a patch, but there's no clear >public acknowledgement from the vendor. But then the vendor didn't ack the bug - the discloser did. Some disclosers are less reliable than others. David