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

RE: [TECH] CD:VAGUE (Vague Vendor Descriptions of Vulnerabilities)


>From: Steven M. Christey [mailto:coley@linus.mitre.org] 

>Adam Shostack said:
>
>>I'm not sure that the existance of a vendor patch should be accepted
as
>>addressing these issues; see the recent Internet explorer roll-up 
>>patch.

And would this be the first time that it has taken some vendor more than
one attempt to truly patch the whole problem?

>Note that MITRE is very careful about assuming that an advisory fixes a
>particular issue.  The Tao of CVE Refinement, which I quote heavily to
>the content team, asks: "If someone claims acknowledgement and the
>vendor says nothing or speaks in riddles, then has the problem been
>fixed?"  

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
Page Last Updated or Reviewed: May 22, 2007